This chapter describes how to upgrade your Enterprise Manager environment with best practices to implement the Standby OMSs using Storage Replication DR architecture.
In particular, this chapter covers the following:
OMSs and agents secured against an application virtual hostname
Each OMS and central agent configured using alias hostname
Each OMS and central agent installed on replicated storage and replicated between sites
Each OMS and central agent installations attached to inventory on replicated storage and replicated between sites
Software Library and BI Publisher storage shared between OMS servers at each site and replicated between sites
Agents installed on each physical host at each site to provide monitoring of the hosts regardless of which site is currently the active site
Environments that have already implemented Standby OMSs using Storage Replication DR architecture configured with best practices can make use of the standard upgrade procedures and do not require the additional steps detailed in this chapter. Environments that have not yet implemented the best practices for the Standby OMSs using Storage Replication DR architecture will need to be transitioned in order to support Disaster Recovery in Enterprise Manager Cloud Control 13c.
To assist with the process of transitioning to the new architecture, a new mode of the installer named Upgrade and Transition to DR Readiness has been created. This new mode is enabled by passing a parameter named UPGRADE_TRANSITION, and is only supported for use on the first OMS, via a standard GUI installation, and requires a specific flow of preparation and post-upgrade steps that must be followed. A software only install followed by ConfigureGC.sh does not provide support for Upgrade and Transition to DR Readiness. In addition, upgrading additional OMSs using Upgrade and Transition to DR Readiness is not supported. In a multi-OMS environment, the additional OMSs must first be deinstalled, the first OMS and related post-upgrade processes associated with the transition must be completed, and then additional OMSs can be deployed.
Install the Enterprise Manager 13c software for the primary OMS on replicated storage
Configure the upgraded Enterprise Manager 13c primary OMS to make use of an alias hostname
Attach the upgraded Enterprise Manager 13c installation to a specified inventory on replicated storage
The Upgrade and Transition to DR Readiness process requires significant preparation and additional steps outside the context of the installer itself. The degree of change required as part of the upgrade and transition process depends upon the degree to which the existing installation follows best practices for the Standby OMSs using Storage Replication DR architecture. The maximum amount of change involves implementation of alias hostnames and relocation of OMS and OMS agent (Central Agent) from installations and inventory on local storage to installations and inventory on replicated storage. Variations of this process can be performed to address environments where only a subset of the configuration changes are required. The following table provides an overview of the process applicable to each scenario.
After additional OMSs are successfully deployed, WebLogic demonstration certificates are regenerated to reflect alias hostnames on all OMS servers; the binaries from the Enterprise Manager 12c OMS on OMS1 are deinstalled; and physical hostname agents are deployed to all Primary and Standby OMS servers.
Table 5-1 Transitions Supported by Upgrade Modes
| Old Install | Upgraded Install | Old Inventory | Upgraded Inventory | Old Hostname | Upgraded Hostname | Upgrade Mode |
|---|---|---|---|---|---|---|
|
Local or Replicated |
Replicated |
Local |
Replicated |
Physical |
Alias |
Upgrade and Transition to DR Readiness |
|
Local or Replicated |
Replicated |
Local |
Replicated |
Alias |
Same |
Upgrade and Transition to DR Readiness |
|
Local or Replicated |
Replicated |
Replicated |
Same |
Physical |
Alias |
Upgrade and Transition to DR Readiness |
|
Local or Replicated |
Replicated |
Replicated |
Same |
Alias |
Same |
Upgrade |
The upgrade and transition process starts with preparation activities across the environment to ensure readiness. Once the environment is ready, a consistent set of backups of all OMS servers are taken at both sites and the repository database. Once the backups are complete, the deinstallation of the standby OMSs and OMS agents begin. The Standby OMSs are deleted, the Standby OMS agents are deinstalled, and the Standby OMS binaries are deinstalled.
Once the Standby site deinstallation is complete, detailed preparation of servers begins on both sites. The OMS Installation Base directory is identified; Primary and Standby OMS Servers are prepared for replicated storage configuration and for alias hostnames; an Oracle Inventory Location pointer file is created in the Oracle Inventory Directory on replicated storage on Primary OMS1; the Enterprise Manager 13c installation software is staged on Primary OMS1 server; and the local lock file directories are created on all Primary and Standby OMS Servers.
Once the preparation on both sites is complete, additional OMSs and additional OMS agents at the primary site are deleted and deinstalled, and the upgrade and transition of OMS1 begins. The Primary OMS1 and OMS1 agent are stopped, the installer is launched, and the upgrade and transition of OMS1 and the repository begins. After the upgrade and transition of OMS1 completes, OMS1 is stopped, configured for local lock files, and restarted.
At this point, the upgrade and transition of OMS1 Agent begins. The OMS1 Agent is upgraded to Enterprise Manager 13.2; the Post Agent Upgrade Cleanup is performed for the OMS1 Agent; the OMS1 Agent is relocated from local storage and inventory to replicated storage and inventory; steps are taken to prepare and recover the OMS1 Agent to make use of the alias hostname; OMS1 related targets are relocated to the recovered alias hostname agent.
Once the Agent and target relocation is complete, the OMS1 is resecured to make use of the updated Enterprise Manager 13c SLB configuration, the internal channel between the OMS and BI Publisher is configured, and the deferred DDMP jobs are submitted. Once the DDMP Jobs complete, the upgrade and transition of OMS1 is complete and additional OMS deployment begins. An alias hostname agent is deployed to each additional OMS server on replicated storage with inventory on replicated storage. Additional OMSs are deployed using the Add Oracle Management Service deployment procedure.
After additional OMSs are successfully deployed, WebLogic demonstration certificates are regenerated to reflect alias hostnames on all OMS servers; the binaries from the Enterprise Manager 12c OMS on OMS1 are deinstalled; and physical hostname agents are deployed to all Primary and Standby OMS servers.
Note:
In development and test environments that can accommodate the associated downtime, a switchover can be performed to and back from the new standby OMSs to confirm the successful upgrade and transition, and additional patching and other maintenance tests also can be performed.To upgrade your Enterprise Manager 12c Release 5 (12.1.0.5) or 12c Release 4 (12.1.0.4) environment configured with Standby OMSs using Standby WebLogic Domain Disaster Recovery (DR) architecture to Enterprise Manager 13c Release 2 (13.2.0.0) and transition to Standby OMSs using Storage Replication DR architecture, follow these steps:
Step 3: Preparing Primary and Standby OMSs for Upgrade and Transition to DR Readiness
Step 4: Deleting Primary Additional OMSs and Additional OMS Agents
Step 5: Upgrading and Transitioning the OMS1 and the Repository
Step 8: Adding New Primary Additional OMS Alias Hostname Agents and Additional OMSs
This section details the preparation steps required to ensure a successful upgrade and transition. As a general approach, consider preparation for this upgrade and transition to be similar to preparation that you would perform for an upgrade or other heavy maintenance activity. As with those maintenance activities, it is important to ensure that the environment is healthy prior to commencing the upgrade and transition activities.
It is important to understand the entire upgrade and transition process as well as the conventions used in this section. There are two users referenced in the instructions:
Root
Oracle Software Owner User
If there is no reference to the specific user to use for a command, the command should be run as the Oracle Software Owner User. Commands that should be run as root are identified explicitly. If you cannot directly log in as root in your environment, you can make use of sudo or other means to execute the commands as root. If you are using other means to execute the commands as root in your environment, be sure to make the appropriate changes to the commands to ensure they are run with root privileges and test those commands in your development or test environment to ensure they are structured correctly.
Variables are referenced within commands using angle brackets as in <VARIABLE>. As environments can vary substantially, it is possible that direct variable substitution may not work for your environment. In these cases, you must identify the difference between your environment and the example environment reflected in the examples in this section, and adapt the variable substitution to reflect the differences in your environment.
Enterprise Manager servers that contain an OMS are referenced within these instructions individually as an OMS server or OMSn (such as OMS1), and collectively as OMSs or OMS servers. Thus, a reference to an OMS server often includes components besides the OMS, such as BI Publisher if BI Publisher is configured. A reference to Start OMS with the command emctl start oms will start the full product stack installed and configured on the particular OMS server, including OMS, BI Publisher (if configured), WebLogic Node Manager, and WebLogic Administration Server if on OMS1.
Before you proceed with Upgrading Enterprise Manager 12c to 13c Release 2 and Transitioning to DR Readiness, ensure that you have verified the following:
Step 2: Securing Enterprise Manager Installation Against an Application Virtual Hostname
Step 3: Ensuring the Replicated Storage is Provisioned and Currently Active on the Primary Site
Step 4: Ensuring Upgrade and Transition Occurs on the Primary Site
Step 6: Additional Steps Required if Using Custom WLS Certificates Instead of Demonstration Certificates
Step 7: Updating SLB Configuration for the Upgraded Enterprise Manager 13c Environment
Step 8: Creating Backups
The prerequisites for performing an Upgrade and Transition to DR Readiness are a superset of the prerequisites for performing a standard upgrade. Review, understand, and ensure the environment meets the prerequisites specified in Prerequisites for Upgrading to Enterprise Manager Cloud Control 13c Release 2. Ensure that prerequisites not specifically referenced in this chapter are performed at the appropriate time in the upgrade and transition process, no later than before the start of the actual Upgrade and Transition to DR Readiness using the installer. Instructions in this chapter will address when to stop the OMS and OMS agent.
A disaster recovery configuration requires securing the OMS and agents against an application virtual hostname, which can be implemented manually with DNS or in an automated fashion with a global load balancer. Ensure that the OMS and agents have been secured against an application virtual hostname before performing the upgrade and transition. For more information on application virtual hostname, see Application Virtual Host Name Consideration in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
This chapter makes use of the terms replicated storage and storage replication to describe the storage that is used for the installation, configuration, and execution of the OMS and OMS agent software using the alias hostnames. The storage for a given OMS at the primary site is replicated to the corresponding storage at the standby site. The changes are replicated at a minimum on a defined schedule, and on demand before a switchover occurs such that the same installed software and configuration can be accessed by whichever site is active. Depending upon the technologies chosen, there may be manual steps required to be taken by storage administrators in order to change the direction of the replication and prepare the other site’s storage for access. Each OMS (OMS1, OMS2, and so on) has a server at the primary site and at the standby site, and for each OMS only one server is active at any given time. The server at the active site hosts the OMS using the replicated storage.
In addition to the storage replication of OMS and OMS agent software, there are two other sets of storage replication that must be provisioned prior to performing this upgrade and transition process in order to support replication of the Software Library and the BI Publisher shared storage. Storage replication for the Software Library should already be addressed because the Software Library should already be shared between OMSs at a site and replicated between the primary and standby sites as part of the existing two-domain installation. As such, while the Software Library is backed up at the start of this upgrade and transition process, there are no steps incorporated into this upgrade and transition to address preparation of replication of the Software Library. Ensure Software Library replication is configured properly such that the Software Library is currently available on all OMSs at both the primary and standby sites using the same path on all OMSs to support the current two-domain installation, and that it will continue to be available to whichever site is active in the migrated environment.
BI Publisher shared storage needs to be replicated to the standby site such that it can be mounted with the same path, same mount point options, and so on, on each of the standby site OMSs at switchover or failover time. The BI Publisher shared storage at the standby site should make use of the same technology (including software version and configuration options) as that used on the primary site. This chapter does not provide specific instructions to setup or configure storage replication for the BI Publisher shared storage. Before beginning this upgrade and transition process, ensure that each of the OMS servers at the primary and standby sites are configured to be able to mount the replicated BI Publisher shared storage located at the respective site. If BI Publisher is already configured on the primary site, ensure that it is configured to make use of the replicated BI Publisher shared storage as this configuration will be carried forward in the upgrade and transition. If BI Publisher is not yet configured on the primary site, the BI Publisher config and cluster volume directories on the replicated BI Publisher shared storage will need to be specified in the installer. These BI Publisher config volume and cluster volume directories will need to be created on the primary site on the replicated BI Publisher shared storage. Steps in this chapter will ensure the replicated BI Publisher shared storage config and cluster volume directories are specified in the appropriate screen in the installer.
For more information regarding storage replication requirements, see Storage Considerations in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
For more information on BI Publisher High Availability including the BI Publisher shared storage, see BI Publisher High Availability in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
Ensure that the replicated storage has been provisioned as requested, and that the replication is currently configured such that the primary site is active. This will prevent delays during the maintenance window for the upgrade and transition by ensuring that the storage replication is ready to support the upgrade and transition.
The upgrade and transition process will upgrade and transition the Primary WebLogic domain to become the new single WebLogic domain that will be used on both sites.
Ensure that:
The upgrade and transition process is started on the primary site.
You do not use a standby WebLogic domain as the source domain for the upgrade and transition.
Identify the directory to be used as the OMS Installation Base Directory, which is the parent directory for the Middleware Home, Instance Base, Agent Base, and Oracle Inventory locations on the replicated storage. The OMS Installation Base directory can serve as the mount point for the replicated storage. The example configuration of the OMS Installation Base Directory detailed in this chapter is /u01/app/oracle/OMS and is referenced as the variable <OMS_MOUNT_POINT>.
For further details on the OMS Installation Base Directory, see Oracle Management Service High Availability in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
As part of the transition to alias hostnames, WebLogic Server certificates need to be updated on each OMS to reflect the alias hostname FQDN instead of the physical hostname. The upgrade and transition process includes the instructions required to perform these updates for the default WebLogic Server demonstration certificates. It does not include the instructions required to update custom WLS certificates.
For more details on configuring custom WLS certificates, see Configuring Custom Certificates for WebLogic Server in the Oracle Enterprise Manager Cloud Control Security Guide.
If you use custom certificates for WLS, ensure that you have obtained the needed certificates and understand the steps required to perform the updates at the appropriate point in the upgrade and transition process before proceeding.
SLB configuration updates are required to support Always-On Monitoring (AOM), BI Publisher and Java Virtual Machine Diagnostics (JVMD) SLB configuration requirements in EM 13c. Ensure that the SLB configuration on both primary and standby sites is updated with the new configuration required to support AOM, BI Publisher and JVMD. A future step will resecure the OMS to implement the updated configuration for BI Publisher and JVMD.
For more details on SLB configuration for high availability in EM 13c, see Configuring a Load Balancer in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
For more details on SLB configuration for disaster recovery in EM 13c, see Management Service Disaster Recovery in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
For an example of detailed step by step instructions for configuring an SLB for a site, see the white paper Enterprise Manager 13c Cloud Control Configuring OMS High Availability with F5 BIG-IP Local Traffic Manager.
Full backup of each OMSs relevant directories
Backup of the configuration of each OMS
Backup of the Software Library
Backup of the BI Publisher storage if it is configured
Corresponding backups of the repository database(s)
The backups of the OMSs' relevant directories must include the instance, middleware, agent, and inventory. As the backups of the OMSs' relevant directories are filesystem backups, they must be performed as root and must be performed while the OMS and the agent are down. These backups can be performed in a staggered manner, for a single OMS at a time, to ensure availability. Each OMS must be backed up.
A single corresponding backup of the Software Library is required.
If BI Publisher is configured, a single corresponding backup of the BI Publisher config and cluster volumes is also required. Corresponding backups of the database must also be taken or identified.
For more information on backing up Enterprise Manager, see Backing Up and Recovering Enterprise Manager in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
To prepare the Primary and Standby OMSs for Upgrade and Transition to DR Readiness follow these steps:
Step 1: Preparing All Primary and Standby OMS Servers for Replicated Storage Configuration
Step 2: Preparing All Primary and Standby OMS Servers for Alias Hostnames
Step 3: Creating Inventory Location Pointer File in Oracle Inventory Directory on Primary OMS1
Step 4: Staging Enterprise Manager 13c Installation Software on Primary OMS1 Server
Step 5: Preparing Local Lock File Directory on All Primary and Standby Site OMSs
Configure all Primary and Standby OMS Servers for replicated storage. Each corresponding Primary and Standby OMS server must be configured to mount replicated storage containing the Middleware Home, Instance Base, Agent Base, and Oracle Inventory Home. These directories will be used in the upgrade and transition process.
A best practice is to ensure that all four of these directories are located underneath an OMS Installation Base Directory, which can serve as the mount point to the replicated storage. In addition, all OMS servers at each site must be configured to mount the shared storage for BI Publisher and the Software Library, and the shared storage must be shared between all OMS servers at a site and must be replicated between sites. The directory paths must be identical on all OMS servers, for the Middleware Home, Instance Base, Agent Base, Oracle Inventory Home, BI Publisher, and Software Library storage.
Preparation of all the Primary and Standby OMS Servers for replicated storage is complete when:
The replicated storage is active on the primary site
The replicated storage is mounted on the primary site OMS servers
Replication is configured and running on the configured schedule
Ownership and permissions have been set properly on the mounted storage on primary site OMS servers
For more details regarding storage considerations, see Storage Considerations in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
Configure alias host names for all Primary and Standby OMS Servers such that each corresponding OMS host at the Primary and Standby sites is configured with an alias host name that is the same at both the sites. Ensure that all the OMS servers at each site can communicate with all other OMS servers at the same site using the alias host names.
For more details, see Option 2 - Alias host names on both sites in Planning Host Names in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
As a part of the upgrade and transition to replicated storage, the OMS and OMS Agent software must be associated with Oracle Inventory located on replicated storage beneath the OMS Installation Base Directory. Once the upgrade is complete, it will be important to use this Oracle Inventory location for all maintenance of the OMS and OMS Agent to ensure that software maintenance can be performed on whichever site is currently serving as the active site.
Create the Oracle Inventory directory located on replicated storage and create the oraInst.loc Inventory Location pointer file in that directory on Primary OMS1. The Inventory Location pointer file will be used when launching the installer to perform the upgrade to ensure that the upgraded software will be associated with inventory on replicated storage.
For further details, see Configure an Oracle Inventory located under OMS installation base directory in the Oracle Enterprise Manager Advanced Installation and Configuration Guide.
Stage the Enterprise Manager 13c installation software to a directory on the Primary OMS1 Server in preparation for the upgrade.
Create or identify a directory owned by the Oracle Software Owner User located on local storage that can be used to store the local lock file for OHS and configure the directory consistently on all primary and standby OMS servers. In the future steps, you will configure each OMS to make use of this directory for local lock file storage.
Removal of the Standby OMSs and OMS Agents is done through the following steps:
To remove all additional standby OMS instances, see the section on removing additional standby OMS instances in Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
To remove the first standby OMS, see the section on removing the first standby OMS in Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
To remove all of the standby OMS agents, for each standby OMS agent, see the section on Deinstalling Oracle Management Agents in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
To deinstall the binaries for all of the standby OMS instances, for each standby OMS, see the procedure for Deinstalling Enterprise Manager in Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
Note:
Only the additional OMSs and OMS agents are being deleted at this point and hence the instructions in this section are a subset of the instructions in Prerequisites for Deinstalling Only the OMS and Retaining the Management Repository in Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration GuideTo delete Primary Additional OMSs and Additional OMS Agents, follow these steps:
To remove all the additional OMSs at the primary site, you need to stop and delete the additional OMS for each primary additional OMS, separately.
To stop and delete the additional OMS for each primary additional OMS, follow these steps:
To remove all of the primary additional OMS agents, for each primary additional OMS agent, see the section on Deinstalling Oracle Management Agents in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
To deinstall the binaries for all of the primary additional OMS instances, for each primary additional OMS see Procedure for Deinstalling Enterprise Manager in Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
The environment is prepared for the upgrade and transition process. All steps previously listed for the upgrade and transition process are completed.
Prerequisites listed in Prerequisites for Upgrading to Enterprise Manager Cloud Control 13c Release 2 are met.
Primary OMS1 and the Primary OMS1 Agent are stopped before proceeding.
Perform the upgrade and transition of OMS1 and the repository using the following steps:
To upgrade and transition the OMS1 and the repository, follow these steps on Primary OMS1:
Step 4: Running the Prerequisite Checks and Validating the Environment
Step 5: Selecting the Installation Type
Step 6: Configuring a Middleware Home and Validating the Host Name
Step 8: Upgrading or Migrating Plug-ins, or Deploying Dependent Plug-ins
Step 9: Deploying Additional Plug-ins
Step 11: Configuring the Shared Locations for Oracle BI Publisher
Step 12: Configuring the Ports
Step 13: Reviewing the Upgrade Details
Step 14: Monitoring the Upgrade Progress
Step 15: Ending the Upgrade
Oracle strongly recommends that you back up the Management Repository, the OMS, the inventory, the Software Library, and other components that are critical to the functioning of Enterprise Manager. This will enable you to revert to the original contents if the upgrade fails.
Invoke the Enterprise Manager Cloud Control Installation Wizard on the host where your existing OMS1 is running.
./em13200_<platform>.bin -invPtrLoc <absolute_path_to_oraInst.loc_on_replicated_storage> ORACLE_HOSTNAME=<OMS1_ALIAS_HOSTNAME_FQDN> UPGRADE_TRANSITION=true OLD_INVENTORY_LOCATION=<OLD_INVENTORY_HOME>
Example:
./em13200_linux64.bin -invPtrLoc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=emoms1.domain.com UPGRADE_TRANSITION=true OLD_INVENTORY_LOCATION=/u01/app/oracle/oraInventory
Specifying the following parameter and value ensures that the Enterprise Manager Cloud Control 13c installation will be associated with Oracle Inventory located on replicated storage:
-invPtrLoc <absolute_path_to_oraInst.loc_on_replicated_storage>
Specifying the following parameter and value enables the Upgrade and Transition to DR Readiness mode of the installer:
UPGRADE_TRANSITION=true
The following parameter and value specifies the alias hostname to use for the upgraded OMS1:
Note:
Ensure that the Host Name field on the Installation Details page is reviewed and updated if necessary to match the alias hostname of OMS1.ORACLE_HOSTNAME=<OMS1_ALIAS_HOSTNAME_FQDN>
The following parameter and value specifies the directory of the old Oracle Inventory associated with the Enterprise Manager Cloud Control installation that is being upgraded:
OLD_INVENTORY_LOCATION=<OLD_INVENTORY_HOME>
(Optional) On the My Oracle Support Details screen, enter your My Oracle Support credentials to enable Oracle Configuration Manager, and click Next. If you do not want to enable Oracle Configuration Manager now, click Next without entering any details, and go to Applying the Latest Software Updates.
If the host from where you are running the installation wizard does not have a connection to the Internet, then enter only the e-mail address and leave the other fields blank. After you complete the installation, manually collect the configuration information and upload it to My Oracle Support. For instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
On the Software Updates screen, apply the latest software updates, including the latest PSU patches, click Next.
You can download the software updates in offline mode (if you do not have Internet connectivity) or online mode (if you have Internet connectivity). For instructions, see Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
On the Prerequisite Checks screen, check the status of the prerequisite checks run by the installation wizard, and verify whether your environment meets all the minimum requirements for a successful upgrade. Then click Next.
The installation wizard runs the prerequisite checks automatically when you come to this screen. The status of the prerequisite check can be either Warning, Failed, Succeeded, Not Executed, In Progress, or Pending.
If some checks result in Warning or Failed status, then investigate and correct the problems before you proceed with the upgrade. The screen provides details on why the prerequisites failed and how you can resolve them. After you correct the problems, return to this screen and click Rerun to check the prerequisites again.
On the Installation Details page, follow these steps:
On the Database Connection Details page, select Disable DDMP Jobs, and follow the remainder of the instructions in Providing Database Connection Details. The DDMP Jobs will be submitted later in the upgrade and transition process.
On the Plug-In Upgrade screen, review the plug-ins that will experience one of the following effects, and click Next.
Upgraded when newer versions exist
Migrated when newer versions do not exist
Deployed when the plug-ins being upgraded have new dependencies, or when there are any new default plug-ins introduced with a release.
Here, newer versions refer to the newer versions of plug-ins available in the Enterprise Manager software (DVD, or downloaded software) that you are using to install.
Note:
You might have a deprecated plug-in in your environment that can be upgraded to a plug-in version that is supported only in 13c Release 2 but not in any of the future releases. If such a deprecated plug-in is selected by default in this screen for upgrade, then you are prompted to evaluate your selection and decide whether or not you want to proceed with the upgrade of such plug-ins.
Note:
Before you proceed to the next screen, run the following command to stop all the associated OMS instances. Here, <ORACLE_HOME> is the Oracle home of the OMS.
$<ORACLE_HOME>/bin/emctl stop oms -all
Note:
If the newer versions do not exist in the Enterprise Manager software that you are using, but exist on Oracle Technology Network (OTN), then you can choose to manually download them from OTN and upgrade your existing plug-ins, instead of having them automatically migrated by default. To do so, follow these steps:
Manually download the required plug-ins from the following location:
http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/oem-plugins-2882950.html
In addition, if you want to download any partner or customer plug-ins, then download from the following location:
Invoke the installer with the following option and pass the location where the additional plug-ins have been downloaded:
On UNIX platforms:
./em13200_<platform>.bin PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
On Microsoft Windows platforms:
setup_em13200_win64.exe PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
This displays a list of plug-ins available in the software kit (DVD, downloaded software) as well as the plug-ins available in this custom location. You can choose the ones you want to install.
Once the newer versions of the plug-ins are made available, this screen lists those plug-ins as plug-ins that will automatically be upgraded.
If you see a message stating that you have unsupported plug-ins on the OMS or on some of the Management Agents, then follow the instructions outlined in the message to upgrade the plug-ins, and then retry upgrading the OMS.
On the Select Plug-ins screen, select the optional plug-ins you want to deploy in addition to the plug-ins that will automatically be upgraded while upgrading the OMS, and click Next.
Note:
If you select a deprecated plug-in that is supported only in 13c Release 2 but not in any of the future releases, then you are prompted to evaluate your selection and decide whether or not you want to proceed with the deployment of such plug-ins.
Note:
If you want to install some plug-ins that are not listed on this screen, then follow these steps:
Manually download the required plug-ins from the following location:
http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/oem-plugins-2882950.html
In addition, if you want to download any partner or customer plug-ins, then download from the following location:
Invoke the installer with the following option and pass the location where the additional plug-ins have been downloaded:
On UNIX platforms:
em13200_<platform>.bin INSTALL_SWONLY_WITH_PLUGINS=true PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
On Microsoft Windows platforms:
setup_em13200_win64.exe INSTALL_SWONLY_WITH_PLUGINS=true PLUGIN_LOCATION=<absolute_path_to_plugin_software_location>
This displays a list of plug-ins available in the software kit (DVD, downloaded software) as well as the plug-ins available in this custom location. You can choose the ones you want to install.
On the Extend WebLogic Server Domain page, follow the instructions listed in Extending the Existing WebLogic Server Domain.
Note:
The Admin Server Host still lists the physical host name for OMS1. This is ok as the Admin Server will be updated to use the OMS1 alias host name as part of this mode of the upgrade.
Ensure the OMS Instance Base location is located on replicated storage. If the replicated storage is configured at or above the OMS Installation Base directory, and the Middleware Home is beneath the OMS Installation Base directory, no change is required as the OMS Instance Base location will be a peer directory of the Middleware Home by default. For example, /u01/app/oracle/OMS/gc_inst.
If the mount point makes use of NFS mounted storage, a warning appears to place the lock file directory on local storage. A post-upgrade step in the upgrade and transition process will place the http lock file in a directory on local storage after the upgrade completes
On the Enterprise Manager Shared Location Details screen, do the following, and click Next.
If you are upgrading an OMS that already has Oracle BI Publisher installed and configured in a shared location, then the fields for configuring Oracle BI Publisher are prefilled and grayed out. You can leave them as they are and proceed to the other sections of this screen.
However, if you are upgrading an OMS that does not already have Oracle BI Publisher installed, or if you are upgrading an OMS that has Oracle BI Publisher installed but not configured in a shared location, then do the following:
(i) Identify a shared location that you can use for Oracle BI Publisher.
If you do not have an existing shared location, create a new one and ensure that it is visible on the host where you are installing the first OMS and also on other hosts where you plan to install additional OMS instances.
At install time, for the installation to be successful, you can reserve approximately 400 MB of hard disk space for the shared directory. However, Oracle recommends that you scale it to at least 10 GB eventually, and ensure that it can be extended further in the future because the space utilization increases over a period of time as you install additional plug-ins and create more reports.
Caution:
If you already have a shared location that you were using for the Software Library or for staging gold images in the previous release of Enterprise Manager, then you can choose to use the same location. However, ensure that the directories within the shared location are unique for Oracle BI Publisher, Software Library, and staged gold images. For example, if you already are using the shared location /u01/software/examplehost/shrd/ where the Software Library is configured in /u01/software/examplehost/shrd/SW, then you can use the same location, but make sure the directory within this shared location for Oracle BI Publisher is /u01/software/examplehost/shrd/BIP.
(ii) On this screen, select Configure a Shared Location for Oracle BI Publisher. Enter the following directory paths. Ensure that the user account that you are using to install the first OMS has read and write permission on these paths.
Note:
When you invoke the installer on Microsoft Windows, the Enterprise Manager Shared Location Details screen does not show the Config Volume and Cluster Volume options. This is an expected behavior.
For Config Volume, enter the path leading up to the /config directory on the shared storage location where Oracle BI Publisher repository and configuration files can be stored. For example, /u01/software/examplehost/shrd/BIP/config
For Cluster Volume, enter the path leading up to the /cluster directory on the shared storage location where Oracle BI Publisher scheduler storage can be maintained for Oracle BI Publisher to operate in a high-availability environment. For example, /u01/software/examplehost/shrd/BIP/cluster
WARNING:
Do not delete these directories after the installation. The directories are required for proper functioning of Oracle BI Publisher, and therefore will still be required after the installation.
Enable or disable the installed and configured Oracle BI Publisher. Enabling Oracle BI Publisher starts the software and keeps it ready for use within the Enterprise Manager system. Disabling Oracle BI Publisher leaves the software as it is without starting it.
To enable Oracle BI Publisher, select Enable Oracle BI Publisher.
Note:
If you choose to disable Oracle BI Publisher during the installation, then you can enable it after the installation by running the following EM CTL command from the Oracle home of the upgraded OMS.
$<ORACLE_HOME>/bin/emctl config oms -enable_bip
For example,
/u01/software/em13c/oraclehome/bin/emctl config oms -enable_bip
The command only enables Oracle BI Publisher, but does not start it. To start it, run the following command from the Oracle home of the upgraded OMS.
$<ORACLE_HOME>/bin/emctl start oms -bip_only
/u01/software/em13c/oraclehome/bin/emctl start oms -bip_only
On the Port Configuration Details screen, customize the ports to be used for the new components being added for this release, and click Next.
The ports for most components are automatically carried over from the previous release, and therefore, this screen lists only the ports for the new components being added for this release.
Note:
If all the ports on this screen appear as -1, then it indicates that the installer is unable to bind the ports on the host. To resolve this issue, exit the installer, verify the host name and the IP configuration of this host (ensure that the IP address of the host is not being used by another host), restart the installer, and try again.
You can enter a free custom port that is either within or outside the port range recommended by Oracle.
To verify if a port is free, run the following command:
On Unix:
netstat -an | grep <port no>
On Microsoft Windows:
netstat -an|findstr <port_no>
However, the custom port must be greater than 1024 and lesser than 65535. Alternatively, if you already have the ports predefined in a staticports.ini file and if you want to use those ports, then click Import staticports.ini file and select the file.
Note:
If the staticports.ini file is passed during installation, then by default, the ports defined in the staticports.ini file are displayed. Otherwise, the first available port from the recommended range is displayed.
The staticports.ini file is available in the following location:
<Software_Extracted_Location>/response
On the Review screen, review the details you have provided for the upgrade.
The installer performs only the software install with plug-ins and this step is part of the process. There is no actual upgrade in progress.
Note:
When performing an Upgrade and Transition to DR Readiness, ensure the Host Name displayed is the alias host name for OMS1. If it is not, navigate back to the Installation Details screen and ensure the Host Name is properly specified.On the Install Progress screen, view the overall progress (in percentage) of the upgrade operation and the status of each of the Configuration Assistants.
Note:
If a Configuration Assistant fails, the installer stops and none of the subsequent Configuration Assistants are run until the issue related to the failed Configuration Assistant is resolved. In this case, diagnose the issue, resolve it, and then, click Retry on the Install Progress screen to rerun the Configuration Assistants starting from the Configuration Assistant that failed.
However, if you accidentally exit the installer before clicking Retry, then do NOT restart the installer to reach the same screen; instead, invoke the runConfig.sh script from the Oracle home of the OMS to rerun the Configuration Assistant in silent mode. If the runConfig.sh script fails, raise a service request and contact Oracle Support.
$<ORACLE_HOME>/oui/bin/runConfig.sh ORACLE_HOME=<absolute_path_to_Middleware_home> MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}
For example,
/u01/software/em13c/oraclehome/oui/bin/runConfig.sh ORACLE_HOME=/u01/software/em13c/oraclehome MODE=perform ACTION=configure COMPONENT_XML={encap_oms.1_0_0_0_0.xml}
If the runConfig.sh script fails, raise a service request and contact Oracle Support.
If the Management Repository upgrade fails with the following error in the schemamanager logs, then restart the database, and then try the upgrade again.
ORA-04020: deadlock detected while trying to lock object SYSMAN.MGMT_GLOBAL
On the Finish screen, you should see information pertaining to the upgrade of Enterprise Manager. Review the information and click Close to exit the wizard.
Once the software binaries are copied and configured, you are prompted to run the allroot.sh script. Open another window, log in as root, and manually run the scripts.
If you are installing on Microsoft Windows operating system, then you will NOT be prompted to run this script.
Note:
If you installed an NFS-mounted drive and created the OMS instance base directorygc_inst on that NFS-mounted drive, then move the lock files from the NFS-mounted drive to a local file system location. To do so, modify the lock files location in the httpd.conf file to map to a location on a local file system.To transition the OMS1 Agent to DR Readiness follow these steps:
Step 1: Upgrading the OMS1 Agent to Enterprise Manager 13c Release 2
Step 2: Verifying the OMS1 Agent Upgrade
Step 3: Performing Post Agent Upgrade Cleanup for the OMS1 Agent
Step 4: Relocating the OMS1 Agent From Local Storage and Inventory to Replicated Storage and Inventory
Step 5: Preparing to Redeploy OMS1 Agent Using Alias Hostname
Step 7: Relocating OMS1 Targets to Alias Hostname OMS1 Agent
Step 8: Reviewing and Updating Target and Configuration Information in Enterprise Manager
Step 9: Decommissioning the Physical Hostname OMS1 Agent That No Longer Exists
To upgrade the OMS1 Agent to Enterprise Manager 13c release 2, follow these steps using the command listed with each step:
Verify that the OMS1 Agent was successfully upgraded to Enterprise Manager 13c Release 2 following the instructions in Verifying Your 13c Management Agent Upgrade.
After confirming that the OMS1 Agent was successfully upgraded to Enterprise Manager 13c Release 2, cleanup the previous version of the OMS1 agent installation by following the instructions in Performing Postupgrade Cleanup of Old Management Agents.
To relocate the OMS1 Agent from its location on local storage registered with the local Oracle Inventory to a location on replicated storage registered with the replicated storage Oracle Inventory, follow these steps using the command listed with each step:
Note:
These instructions are based on the instructions in Moving the Central Agent Base Directory Outside Oracle Middleware Home. However, it is important to note that there is an additional parameter beyond those instructions in the documentation that must be provided to the command in order to make use of a different Oracle Inventory for the new location.The OMS1 Agent uses the existing installation on replicated storage in order to configure the OMS1 Agent with the alias hostname. To prepare to redeploy OMS1 Agent using alias hostname, follow these steps using the command listed with each step:
To redeploy the OMS1 Agent using the alias hostname instead of the physical hostname, follow these steps using the command listed with each step:
To relocate the OMS1 related targets associated with the physical hostname agent to the alias hostname agent, follow these steps using the command listed with each step:
To ensure that the WebLogic Admin console can be accessed from a link using the Enterprise Manager console, update the URL for the WebLogic Admin console. To update the URL using the Enterprise Manager console, follow these steps:
To update the Primary Site Configuration, follow these steps:
The SLB should be updated to include required Enterprise Manager 13c configuration as part of the preparation for this upgrade and transition process. This step will resecure the configuration of OMS1 to make use of the updated configuration in the SLB for Enterprise Manager 13c for BI Publisher and JVMD.
For more details on SLB configuration for high availability in Enterprise Manager 13c, please see Configuring a Load Balancer in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
For more details on SLB configuration for disaster recovery in Enterprise Manager 13c, please see Management Service Disaster Recovery in theOracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
For an example of detailed step by step instructions for configuring an SLB for a site, please see the white paper Enterprise Manager 13c Cloud Control Configuring OMS High Availability with F5 BIG-IP Local Traffic Manager
Note:
It is important to ensure that the emctl secure oms command is run with the same-host, -slb_port, and -slb_console_port used when the OMS was originally secured for the SLB configuration so that agents need not be resecured. If the SLB configuration needs to be changed more substantially, ensure that agents are resecured appropriately.To resecure the OMS1 to include the updated Enterprise Manager 13c SLB configuration, follow these steps:
Beginning with Enterprise Manager 13.1, communication from the Oracle Management Service to BI Publisher can be configured to go through the SLB, ensuring that all operations that require this communication will also be routed through the SLB.
For more information on the internal channel, see Paths to Access BI Publisher in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
To configure the internal channel for BI Publisher follow these steps:
The DDMP jobs were disabled earlier during the upgrade when the Disable DDMP Jobs option was selected in the installer on the Database Connection Details page. For more details on the DDMP jobs, seeTracking the Status of Deferred Data Migration Jobs
To submit the DDMP jobs, Follow these steps:
Not Started.To add new Primary Additional OMS alias hostname agents and Additional OMSs follow these steps:
In the Enterprise Manager, deploy an agent to the alias host name of each Primary Additional OMS server. Review the information below and use this information when following the instructions in Installing Standalone Management Agents Using Add Host Targets Wizard in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.
In Enterprise Manager, deploy an additional OMS, one at a time, using the alias host name agent of each Primary Additional OMS server. Review the information below and use this information when following the instructions in Adding an Additional Oracle Management Service in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.
To finalize Primary and Standby site configuration follow these steps:
If your site uses Demonstration WebLogic Certificates, the certificates need to be recreated with alias hostnames to ensure that WebLogic communication will work properly on both the sites. Follow the steps in Updating Demonstration Keystores to Reflect Alias Hostnames in the Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.
To deinstall the binaries for the Enterprise Manager 12c OMS on the Primary OMS1 server, see Deleting the Old OMS Home When the Central Agent Is Migrated to a Location Outside the Old Middleware Home.
In Enterprise Manager, deploy an agent to the physical host name of each Primary and Standby OMS server. Review the information below and use this information when following the instructions in Installing Standalone Management Agents Using Add Host Targets Wizard in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.
To ensure agents on all OMS nodes have correct time zone configuration, follow these steps.
To perform Post-Upgrade and Transition activities follow these steps:
At this point, steps specific to the upgrade and transition process are complete. Review the post-upgrade activities referenced in the Oracle Enterprise Manager Cloud Control Upgrade Guide to ensure that any remaining tasks required in your environment have been completed. Pay particular attention to steps that have not yet been accomplished as part of the upgrade and transition process, such as upgrading management agents on systems other than the OMS servers, upgrading JVMD agents, and performing any other steps appropriate in your environment such as reconfiguring WebLogic with custom certificates.
This step is intended to build confidence in the upgraded and transitioned environment in a test or development environment. These steps involve downtime and require planning to identify specific patches and plug-ins to deploy. Oracle recommends that switchover testing be scheduled at the first reasonable opportunity following the completion of the upgrade and transition such that any issues are identified and resolved to ensure the successful availability of the standby to protect against unplanned and planned outages, and to provide operations personnel familiarity with the new standby configuration and switchover processes..
Patching Considerations:
When using OMSPatcher to perform patching, set the following property to disable the host verification check due to the alias hostnames configuration.
OMSPatcher.OMS_DISABLE_HOST_CHECK=true
Oracle Inventory Considerations:
Now that the upgrade and transition is complete, there are two sets of Oracle Inventory locations that need to be considered when performing any maintenance in the EM environment: local storage Oracle Inventory and replicated storage Oracle Inventory. This upgrade and transition process did not make any changes to the central Oracle Inventory pointer located in /etc/oraInst.loc. It is possible that this pointer may reference the replicated storage Oracle Inventory, the local storage Oracle Inventory, or perhaps even a different Oracle Inventory. The key is to ensure that when you are performing maintenance operations that you are aware of the Oracle Inventory that should be used for the particular installed software. Operations against the locally installed software such as the local agents should be performed against the local storage Oracle Inventory. Operations against the software installed on replicated storage such as the OMS and OMS agent should be performed against the replicated storage Oracle Inventory so that the software installed on replicated storage can be maintained regardless of which physical host is currently hosting the software.
When you are certain of upgrade and transition success and that you will no longer need to fall back from the upgrade and transition, and once any logs, configuration, or other long-term reference information has been copied or backed up via other means as necessary, you can remove temporary directories, backups, directories related to old installations, and so on, that were made on local and replicated storage as part of the upgrade and transition process.
The following are a list of the areas to review:
Review the following directories on Primary OMS1:
Renamed agent base directory prior to running agentDeploy.sh
<NEW_OMS_AGENT_BASE>/agent_inst.YYYYMMDD
Example:
/u01/app/oracle/OMS/oms_agent/agent_inst.20160502
Staging directory used for the EM 13.2 installer
<UPGRADE_STAGING_DIR>
Example:
/u01/app/oracle/OMS/stage
Review the following on all Primary and Standby OMS servers:
Instance Base directories from the EM 12c installations which have been deinstalled.
<OLD_INSTANCE_BASE>
Example:
/u01/app/oracle/gc_inst
Backups taken before or during this upgrade and transition process.
<BACKUP_DIR>
Example:
/u01/app/oracle/local/backup
Scheduled jobs, such as via cron, that reference the EM 12c software and/or environment.
<BACKUP_DIR>
Example:
crontab -l