Before you use the upgrade approaches to upgrade to Enterprise Manager Cloud Control, keep these points in mind:
Supported OMS Environments for Upgrading an Enterprise Manager System
Supported Upgrade Paths and Supported Upgrade Approaches for Upgrading an Enterprise Manager System
Platforms Supported for Upgrading an Enterprise Manager System
Upgrade Scope Offered for Upgrading an Enterprise Manager System
Modified or Customized Data After Repository Backup That Are Not Migrated Via ADMP
Upgrading Plug-Ins While Upgrading an Enterprise Manager System
Status of Oracle Software Library After Upgrading an Enterprise Manager System
Updating the PDP Configuration File After Upgrading an Enterprise Manager System
XML DB Feature in the Database After Upgrading an Enterprise Manager System
Manually Restarting the OMS and the Management Agent After Upgrading an Enterprise Manager System
You can upgrade any of the following OMS environments:
Single-OMS Environments: A single-OMS environment is an environment with one OMS that orchestrates with multiple Management Agents. Typically, small deployments.
Multi-OMS Environments: A multi-OMS environment is an environment with two or more OMS instances moderated with a Server Load Balancer (SLB) that orchestrates with multiple Management Agents. Typically, large deployments.
Table 3-1 lists the supported upgrade paths, and the upgrade approach supported for each upgrade path.
Table 3-1 Supported Upgrade Paths and Supported Upgrade Approaches for Upgrading an Enterprise Manager System
| Upgrade From | Upgrade To | Supported Upgrade Approach |
|---|---|---|
|
12c Release 4 (12.1.0.4) |
12c Release 5 (12.1.0.5) |
1-System Upgrade |
|
12c Release 3 Plug-in Upgrade 1 (12.1.0.3) (12c Release 3 (12.1.0.3) software with plug-ins released in October 2013) |
12c Release 5 (12.1.0.5) |
1-System Upgrade |
|
12c Release 3 (12.1.0.3) |
12c Release 5 (12.1.0.5) |
1-System Upgrade |
|
12c Release 2 Plug-in Update 1 (12.1.0.2) (12c Release 2 (12.1.0.2) software with plug-ins released in February 2013) |
12c Release 5 (12.1.0.5) |
1-System Upgrade |
|
12c Release 2 (12.1.0.2) |
12c Release 5 (12.1.0.5) |
1-System Upgrade |
|
12c Release 1 (12.1.0.1) patched with Bundle Patch 1 |
First upgrade to either 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3), or 12c Release 4 (12.1.0.4), and then upgrade to 12c Release 5 (12.1.0.5). |
N/A |
|
12c Release 1 (12.1.0.1) containing Bundle Patch 1 (included by default) |
First upgrade to either 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3), or 12c Release 4 (12.1.0.4) and then upgrade to 12c Release 5 (12.1.0.5). |
N/A |
|
12c Release 1 (12.1.0.1) (base release) |
First upgrade to either 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3), or 12c Release 4 (12.1.0.4), and then upgrade to 12c Release 5 (12.1.0.5). |
N/A |
|
11g Release 1 (11.1.0.1) |
12c Release 5 (12.1.0.5) |
|
|
10g Release 5 (10.2.0.5) |
12c Release 5 (12.1.0.5) |
|
|
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 5 (12.1.0.5) |
N/A |
|
10g Release 1 (10.1) |
First upgrade to 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1), then upgrade to 12c Release 5 (12.1.0.5) |
N/A |
The following platforms are supported for upgrading an Enterprise Manager system:
1-System upgrade, understandably, must always be done on the same platform as the earlier release of the Enterprise Manager system because you are upgrading on the same host.
2-System upgrade and 1-System upgrade on a different host are possible on the same platform as the earlier release of the Enterprise Manager system, or any platform that is supported for Enterprise Manager Cloud Control 12c. For information on the certified platforms, see the Enterprise Manager certification matrix as described in Oracle Enterprise Manager Cloud Control Basic Installation Guide.
The following are some facts about the upgrade approaches:
You can choose to use either 1-System, 2-System, or 1-System upgrade approach on a different host. However, regardless of the approach you choose, the upgrade operation is always an out-of-place upgrade where you see new Oracle homes of Oracle Management Service (OMS) and Oracle Management Agent (Management Agent).
As a best practice, back up your old and new homes regularly.
For upgrading an additional OMS, always choose to use only 1-System upgrade approach.
The upgrade approaches do NOT upgrade your existing database where the Management Repository is configured.
To upgrade such databases, use the database upgrade tool. For more information, on the upgrade tool, see the Oracle Database Upgrade Guide available in the Oracle Database documentation library at:
http://www.oracle.com/technetwork/indexes/documentation/index.html
Oracle Management Service 12c can communicate only with the following versions of Oracle Management Agent 12c:
Table 3-2 Compatibility Between OMS and Management Agents Across 12c Releases
|
Oracle Management Agent 12c Release 1 (12.1.0.1) + Bundle Patch 1 (Refers to agents and their plug-ins patched or upgraded to, or installed with Bundle Patch 1) |
Oracle Management Agent 12c Release 2 (12.1.0.2) |
Oracle Management Agent 12c Release 3 (12.1.0.3) |
Oracle Management Agent 12c Release 4 (12.1.0.4) |
Oracle Management Agent 12c Release 5 (12.1.0.5) |
|
|
Oracle Management Service 12c Release 1 (12.1.0.1) + Bundle Patch 1 |
Yes (includes Management Agents with and without Bundle Patch 1) |
No |
No |
No |
No |
|
Oracle Management Service 12c Release 2 (12.1.0.2) |
Yes (includes Management Agents with and without Bundle Patch 1) |
Yes |
No |
No |
No |
|
Oracle Management Service 12c Release 3 (12.1.0.3) |
Yes (Only Management Agents released in January 2012 [with Bundle Patch 1]) |
Yes |
Yes |
No |
No |
|
Oracle Management Service 12c Release 4 (12.1.0.4) |
No |
Yes |
Yes |
Yes |
No |
|
Oracle Management Service 12c Release 5 (12.1.0.5) |
No |
Yes |
Yes |
Yes |
Yes |
You can upgrade any Management Agent on any platform as long as the Oracle Management Agent 12c software for that platform is available.
The Enterprise Manager Cloud Control Installation Wizard installs Java Development Kit (JDK) 1.6.0.43.0 and Oracle WebLogic Server 11g Release 1 (10.3.6) if they do not exist in your environment.
If Oracle WebLogic Server 11g Release 1 (10.3.6) does not exist, then Oracle recommends you to allow the installation wizard to install it for you. However, if you want to manually install it, then ensure that you install it using JDK 1.6.0.43.0 (64-bit version for 64-bit platforms and 32-bit version for 32-bit platforms).
Download JDK 1.6.0.43.0 for your platform from the platform vendor's Web site.
For example, download SUN JDK 1.6.0.43.0 for Linux platforms from the following Oracle Web site URL:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
If you already have JDK, then verify its version by navigating to the <JDK_Location>/bin directory and running the following command:
"./java -fullversion"
To verify whether it is a 32-bit or a 64-bit JDK, run the following command:
"file *"
If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.6) on Linux 64-bit platforms, first install the 64-bit JDK for your platform, and then download and use the wls1036_generic.jar file to install Oracle WebLogic Server.
For example,
<JDK home>/bin/java -d64 -jar <absolute_path _to_wls1036_generic.jar>
If you want to manually install Oracle WebLogic Server 11g Release 1 (10.3.6) on Linux 32-bit platforms, then download and use either the wls1036_linux32.bin file or the wls1036_generic.jar file.
For example,
<JDK home>/bin/java -jar <absolute_path _to_wls1036_generic.jar>
You must follow the instructions outlined in the Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server to install Oracle WebLogic Server. The guide is available in the Fusion Middleware documentation library available at:
http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html
You must ensure that the Oracle WebLogic Server installation is a typical installation, and even if you choose to perform a custom installation, ensure that components chosen for custom installation are the same as the ones associated with a typical installation.
You must ensure that the user installing the WebLogic Server is the same as the one installing Enterprise Manager Cloud Control.
After installing Oracle WebLogic Server, as a postinstall step, apply the patches 14482558, 13349651, and 16080294 on it. Without these patches, the additional OMS installation will fail. However, these patches are required only if you are manually installing the Oracle WebLogic Server.
For instructions to apply these patches, see the following URL:
http://docs.oracle.com/cd/E14759_01/doc.32/e14143/intro.htm#CHDCAJFC
For more information on Oracle WebLogic Server downloads and demos, access the following URL:
http://www.oracle.com/technology/products/weblogic/index.html
You must ensure that the Oracle WebLogic Server 11g Release 1 (10.3.6) installed by the Enterprise Manager Cloud Control Installation Wizard or by you is dedicated for Enterprise Manager Cloud Control. You must not have any other Oracle Fusion Middleware product installed in that Middleware home.
Enterprise Manager Cloud Control cannot coexist with any Oracle Fusion Middleware product in the same Middleware home because the ORACLE_COMMON property is used by both the products.
After upgrading from 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1) to 12c Release X (12.1.0.X) using the 2-system upgrade approach, a post-upgrade activity called Accrued Data Migration is run to migrate all accrued data stored in the old Management Repository to the upgraded Management Repository. The accrued data relates to functional areas such as blackouts, alerts, events, metrics, and so on. For more information on Accrued Data Migration, see Section 13.8.1.
However, this Accrued Data Migration process does not migrate any of the following changes if they were done after the Management Repository was backed up. If you want these changes in the upgraded Enterprise Manager system, you must manually redo these changes after upgrade.
Security data (new users created, passwords changed)
Jobs created, deleted, or submitted
Customized deployment procedures
Patches
Targets added or deleted
Reports created, modified, or deleted
Software Library configuration changes
Templates created, modified, or deleted
User-defined metrics
When you upgrade your Management Agents, the ports used by the earlier release of the Management Agents are carried over to the upgraded Management Agents. Therefore, your firewall settings are not affected in any way.
When you upgrade your OMS, the following ports are assigned:
For 2-System upgrade approach, new ports that you accept or specify in the installer are assigned to all the core components.
For 1-System upgrade approach, the following is the behavior:
If you are upgrading 12c Release 4 (12.1.0.4), 12c Release 3 (12.1.0.3), or 12c Release 2 (12.1.0.2), then the ports used by all the core components of the earlier release are carried over.
If you are upgrading 10g Release 5 (10.2.0.5) or 11g Release 1 (11.1.0.1), then the ports used by the following core components of the earlier release are carried over. For the rest of the core components, new ports that you accept or specify in the installer are assigned.
Enterprise Manager Upload HTTP Port
Enterprise Manager Upload HTTP SSL Port
Enterprise Manager Central Console HTTP Port
Enterprise Manager Central Console HTTP SSL Port
Oracle Management Agent
For 1-System upgrade approach on a different host, new ports that you pass in a response file while configuring the OMS are assigned to all the core components.
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.For information about what URLs should be made available through a firewall, when a firewall is configured for the OMS, see Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
This section describes the following:
This section describes how plug-ins are upgraded while upgrading Oracle Management Agents and Oracle Management Service of 12c Release 4 (12.1.0.4), 12c Release 3 (12.1.0.3), or 12c Release 2 (12.1.0.2) to 12c Release 5 (12.1.0.5).
In particular, this section describes the following:
While upgrading Oracle Management Agents 12c Release 4 (12.1.0.4), 12c Release 3 (12.1.0.3), or 12c Release 2 (12.1.0.2) to 12c Release 5 (12.1.0.5) using the Agent Upgrade Console, all plug-ins of the earlier release are upgraded by default. No manual effort is required.
While upgrading Oracle Management Service 12c Release 4 (12.1.0.4), 12c Release 3 (12.1.0.3), 12c Release 2 (12.1.0.2) to 12c Release 5 (12.1.0.5) using the Enterprise Manager Cloud Control Installation Wizard, plug-ins are automatically upgraded, migrated, or deployed under the following circumstances:
Plug-ins are upgraded when newer versions exist
Plug-ins are migrated when newer versions do not exist
Plug-ins are deployed when the plug-ins being upgraded have new dependencies, or when there are any new default plug-ins introduced with a release.
In addition, the installation wizard provides a Select Plug-ins screen that enables selection of the optional plug-ins you want to deploy in addition to the plug-ins that will automatically be upgraded, migrated, or deployed.
If you want to install plug-ins that are not listed on the Select Plug-ins screen, then follow these steps:
Access the following Enterprise Manager download page on Oracle Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html
Expand the section that lists the software binaries and plug-ins for your upgrade path.
From the Download Plug-ins section, manually download the plug-ins and store them in an accessible location.
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>
To identify the plug-ins required for upgrade, in the Preupgrade Console, in the Preupgrade Steps section, click Manage Software. On the Manage Software page, view the plug-ins that are required for upgrading your system.
The plug-ins listed on the Manage Software page are based on the targets monitored by the old Management Agents in your existing system, and also based on the new plug-in requirement Enterprise Manager Cloud Control has. You need only the plug-ins listed on this page to successfully upgrade your existing system.
This section describes how you can download and install the required plug-ins while upgrading Oracle Management Agents 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1), and Oracle Management Service 10g Release 5 (10.2.0.5), 11g Release 1 (11.1.0.1).
In particular, this section covers the following:
To install the required plug-ins while upgrading the Management Agents, follow these steps:
Access the following URL:
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html
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.
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.In the Preupgrade Console, on the Manage Software page (Preupgrade Steps section), in the Provide Software Location section, enter the absolute path to the directory where the plug-in is present, and click Validate to register that location with the Management Repository.
See:
For information about registering and validating the plug-in location, see Section 10.4.To install the required plug-ins while upgrading the OMS, invoke the Enterprise Manager Cloud Control Installation Wizard, and proceed to the Select Plug-ins screen. The screen lists all the required plug-ins you registered via the Preupgrade Console while upgrading the Management Agents. The mandatory ones are selected by default.
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:
Access the following Enterprise Manager download page on Oracle Technology Network (OTN):
http://www.oracle.com/technetwork/oem/grid-control/downloads/oem-upgrade-console-502238.html
Expand the section that lists the software binaries and plug-ins for your upgrade path.
From the Download Plug-ins section, manually download the plug-ins and store them in an accessible location.
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>
(This section is applicable only if Software Library was configured in the earlier release of Enterprise Manager)
The following is the status of Oracle Software Library (Software Library) after the Enterprise Manager is upgraded:
For 1-System upgrade approach, the Software Library is functional the moment the Enterprise Manager is upgraded. No manual effort is required to make it functional.
For 2-System upgrade approach, the Software Library is functional only when it is reconfigured after the Enterprise Manager is upgraded.
To understand the 2-System upgrade approach workflow and to know when you must reconfigure the Software Library, see Section 9.2. For information about reconfiguring the Software Library, see Section 13.4.
For 1-System upgrade approach on a different host, the Software Library is functional the moment the Enterprise Manager is upgraded. This is however true only when all the files in the Software Library file system location configured for the old Enterprise Manager system is accessible for read/write from the new host. If not, the upgrade fails.
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.
Enterprise Manager supports Privilege Delegation Providers (PDP) such as SUDO and PowerBroker that enable administrators to restrict certain users from running certain commands. If you have such restrictive PDP configuration setting, then you must ideally enter the location of nmosudo in your configuration file. Management Agent uses nmosudo to run Trusted Jobs in Enterprise Manager.
In Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1], nmosudo was located in the agent instance directory. For example, /u01/oracle/agent/agent_inst/bin/nmosudo.
In Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) or higher, this location has changed. Now, nmosudo is present in the sbin directory, which is in the agent base directory. For example, /u01/oracle/agent/sbin/nmosudo.
Therefore, when you install or upgrade 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1] to 12c Release 2 (12.1.0.2) or higher, you must modify the PDP configuration files to update the new location of nmosudo.
For example, if you use SUDO as your PDP, the configuration file for sudo is typically /etc/sudoers. In this file, update the following entry with the new location to nmosudo.
sudouser ALL : oracle /eminstall/basedir/sbin/nmosudo *
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) to 12c Release X (12.1.0.X).You can ignore this section if you are upgrading within the 12c release, for example, from 12c Release 2 (12.1.0.2), 12c Release 3 (12.1.0.3), 12c Release 4 (12.1.0.4) to 12c Release 5 (12.1.0.5).
This section describes some of the critical changes in Enterprise Manager Cloud Control 12c Release 5 (12.1.0.5) 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:
Deployment Procedures in an Upgraded Enterprise Manager System
Upgrading EM CLI Clients After Upgrading an Enterprise Manager System
Upgrading Oracle Exadata Targets After Upgrading an Enterprise Manager System
During upgrade, the out-of-box rule sets are re-registered, and as a result, you will lose e-mail subscriptions made to them. Therefore, before starting the upgrade process, Oracle strongly recommends that you make a copy (using the Create Like action) of the out-of-box rule sets.
After upgrade, all notification rules and alerts will continue to work in Enterprise Manager Cloud Control. However, note that they have been enhanced and subsumed into a larger and newer concept—Notification Rules are now called Incident Rulesets, and Alerts are now called Events in Enterprise Manager Cloud Control.
For information about Incident Rulesets and how they map to notification rules, and for information about Events and how they map to alerts, see Appendix B.
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:
The following are the ways in which the alerts are migrated:
Table 3-3 shows how and when incidents and events are created for different types of open alerts.
All alerts that were closed 180 days prior to upgrading or backing up the Management Repository are migrated as part of the Deferred Data Migration Process. This period of 180 days can be changed by the administrator.
Table 3-4 shows how and when incidents and events are created for different types of closed alerts. Also note that if a closed alert had an associated ticket, then that information is not captured as part of the event migration.
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 3-3). In addition, all availability records are also migrated as part of the Accrued Data Migration Process.Table 3-3 shows how and when incidents and events are created for different types of open alerts.
Table 3-3 Incidents and Events Created for Different Types of Open Alerts
| Open Alert Type | Incident Created | Event Created |
|---|---|---|
|
Critical Alert |
Yes |
Yes |
|
Warning Alert |
No |
Yes |
|
Critical Alert with Ticket |
Yes |
Yes (with Ticket) |
|
Warning Alert with Ticket |
Yes |
Yes (with Ticket) |
|
Warning Alert with Notification Pending |
Yes |
Yes |
|
Warning Alert without Notification Pending |
No |
Yes |
|
Critical Alert with Acknowledgement |
Yes |
Yes |
|
Warning Alert with Acknowledgement |
Yes |
Yes |
Table 3-4 shows how and when incidents and events are created for different types of closed alerts. Also note that if a closed alert had an associated ticket, then that information is not captured as part of the event migration.
Table 3-4 Incidents and Events Created for Different Types of Closed Alerts
| Closed Alert Type | Incident Created | Event Created |
|---|---|---|
|
Critical Alert |
No |
Yes |
|
Warning Alert |
No |
Yes |
|
Critical Alert with Ticket |
No |
Yes (without Ticket) |
|
Warning Alert with Ticket |
No |
Yes (without Ticket) |
|
Warning Alert with Notification Pending |
No |
Yes |
|
Warning Alert without Notification Pending |
No |
Yes |
|
Critical Alert with Acknowledgement |
No |
Yes |
|
Warning Alert with Acknowledgement |
No |
Yes |
For 1-System upgrade approach, jobs can run more or less as expected. During the downtime, jobs do not run, and any job that is running during the downtime is aborted or failed. In addition, all the scheduled jobs continue as they were planned.
For 2-System upgrade approach, there are some restrictions and caveats on how jobs run. Firstly, since a Management Agent is monitored only by one particular Enterprise Manager system at any point, jobs can run only in the system that monitors the Management Agent. Until a Management Agent is migrated, all jobs against targets monitored by that Management Agent are run in the old Enterprise Manager system. This also means that only one Enterprise Manager system has the true status of a job because the Management Agent communicates only with one of the systems at a given time, so only that Enterprise Manager system knows what the actual status is.
If a Management Agent is not migrated, then a future job appears as a scheduled job in the old Enterprise Manager system, but appears as a suspended job on the Management Agent unavailable in Enterprise Manager Cloud Control.
A job running in the old Enterprise Manager system at the time of the backup either aborts or fails in Enterprise Manager Cloud Control. Once the Management Agent is migrated, a future job appears as a suspended job on the Management Agent unavailable in the old Enterprise Manager system, but appears as a scheduled job in Enterprise Manager Cloud Control. If the Management Agent is subsequently removed from the old Enterprise Manager system, then that job is removed as well.
If the backup of the old Enterprise Manager system did not require a downtime, then the jobs running at the time of the backup continue to run. (If the backup required a downtime, then the job may abort due to the downtime.) Such jobs appear as aborted, failed, or skipped jobs in Enterprise Manager Cloud Control.
Repeating jobs continue to run in the old Enterprise Manager system according to their schedule. In Enterprise Manager Cloud Control, such jobs appear to be aborted, failed, or skipped. Once the Management Agent is migrated, such jobs start to run in Enterprise Manager Cloud Control. In the old Enterprise Manager system, such jobs are suspended on the Management Agent unavailable.
Jobs submitted in the old Enterprise Manager system after the backup do NOT appear in Enterprise Manager Cloud Control. Jobs submitted in Enterprise Manager Cloud Control do NOT appear in the old Enterprise Manager system. Usually, jobs are created only in the system that is currently monitoring the target.
Jobs created in the old Enterprise Manager system before the Management Agent or its targets is migrated run in the old Enterprise Manager system as expected.
Repeating jobs run until the Management Agent is migrated at which point they are stuck as suspended jobs on the Management Agent unavailable.
If jobs are created in the old Enterprise Manager system after the target is migrated, then they never run; they remain stuck as suspended jobs on the Management Agent unavailable. So do not create a job in the old Enterprise Manager system after the Management Agent is migrated.
Jobs created in Enterprise Manager Cloud Control on targets for which the Management Agent has already been migrated behave normally and run as expected.
Jobs can be created in Enterprise Manager Cloud Control before the Management Agent for its target is migrated, but they will be in suspended 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.
After upgrading the entire Enterprise Manager system, none of the 10g Release 5 (10.2.0.5) or 11g Release 1(11.1.0.1) deployment procedure runs will be available in the upgraded Enterprise Manager. If you want to reference any of the old runtime data, then you must use the following EM CLI verb to export all of the runtime data as an XML file.
get_instance_data_xml
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
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.
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.
When you upgrade to 12c Release 5 (12.1.0.5), all custom certificates configured for the upload and console ports of the OMS, and all custom certificates configured for the Management Agents are automatically carried over from the previous release and are preserve d in the upgraded release. You do not have to reconfigure any of these custom certificates.
Enterprise Manager is not affected when you enable or disable features such as XML DB on the Oracle Database in which you plan to configure the Management Repository. Therefore, you can enable or disable any feature in the database because Enterprise Manager does not rely on them.
If you install the OMS and the Oracle Database, which houses the Management Repository, on the same host, then when you reboot the host, the OMS and the Management Agent installed with it will not automatically start up. You will have to manually start them.
If you have Oracle Data Guard configured with your standby database, then enable force logging on the database using the following command:
ALTER DATABASE force logging;
If you do not enable force logging on the database, then use of NOLOGGING commands while upgrading the Enterprise Manager system might corrupt your standby database.