Patching Oracle Management Service and the Repository
OMSPatcher automates the patching process by generating custom patching instructions based your particular environment and then automatically applies the patch. To increase patching flexibility and minimize downtime, OMSPatcher provides a near-zero downtime (Rapid Platform Update) patching option in addition to standard patching.
This chapter covers the following topics:
Standard Patching (normal downtime patching)
Rapid Platform Update Patching (online patching)
OMSPatcher Automation
With OMSPatcher, you can automatically patch a typical OMS configuration (core, plug-in homes) with minimal intervention.
OMSPatcher performs many of the pre-patch checks such as:
-
Configuration-based prerequisite checks
-
Patch-based binary prerequisite checks
OMSPatcher performs end-to-end configuration patching. Configuration patching is the process of patching a target based on its configuration. By incorporating the configuration information into the patch process, OMSPatcher is able to simplify patching tasks by automating most of the steps.
Supported OMS Configurations and OMSPatcher Patchability
-
Single OMS – OMS application that runs from a single OMS instance of the system. OMSPatcher performs patching and deployment operations
-
Multiple OMS – OMS applications that run on two or more hosts. The OMSes are connected by the Oracle WebLogic domain and separate managed servers. There is a one-to-one mapping between the managed servers and the separate OMS bits residing on a single machine. There are two ways in which patches are applied on a multiple OMS setup.
- Automated: A job is automatically submitted that deploys the patches (Linux systems) on each OMS.
- Manual: OMSPatcher provides auto-generated bash scripts (one per OMS instance) for UNIX based systems. OMSPatcher on Linux skips automatic patching on
addOMSes if the-skipautopatch_addomsparameter is passed (one per OMS instance expect primary OMS).OMSPatcher does not support automatic patching of
For both cases, the administrator needs to follow the steps given by OMSPatcher.addOMSes on Windows. For Windows, OMSPatcher provides auto-generated batch scripts, one per OMS instance expect primary OMS.(text and HTML)
-
Single Instance Database or Real Application Cluster - shared or Real Application Cluster (RAC)
Example: Multi-OMS System
The following figure illustrates a multi-OMS deployment. The following terms are used:
-
Administrator: Person installing patches to the OMS core and plug-in homes.
-
Local OMS: OMS instance on which the administrator runs OMSPatcher.
-
Add OMS: OMS instances on other machines (within the same OMS domain as the local OMS) where the administrator has not started any patching operations.
Figure 5-1 Simple Multi-OMS System
For a single OMS system (primary), OMSPatcher will execute the patching steps. For a multi-OMS UNIX system, a job is automatically submitted to deploy the patches. If you need to deploy the patches manually, OMSPatcher generates bash scripts for execution, one per OMS instance for all OMSes (except the primary OMS); follow the instructions given by OMSPatcher to find those scripts. For Windows multi-OMS systems, OMSPatcher will generate bash scripts for all OMSes except the primary OMS.
Oracle Universal Installer Inventory Configurations (OUI)
Apart from the target or instance-based configuration, OMSPatcher utilizes installation configuration relationships established in the OUI inventory as core and plug-in feature-sets. A typical OMS 13c home is organized as follows:
<Middleware Home>
├── <CORE_BITS>
...
├── OMSPatcher
│ ├── jlib
│ ├── oms
│ ├── omspatcher
│ ├── omspatcher.bat
│ ├── restoring_env.txt
│ ├── scripts
│ ├── version.txt
│ └── wlskeys
├── OPatch
│ ├── auto
│ ├── bin
│ ├── docs
│ ├── emdpatch.pl
│ ├── jlib
│ ├── ...
...
├── plugins
│ ├── backup
│ ├── oracle.em.savf.oms.plugin_13.5.1.0.0
│ ├── oracle.em.smis.oms.plugin_13.1.1.0.0
│ └── tmp
...Supported Patch Format
Enterprise Manager patches have been converted to a System patch format in order to support patch automation.
What is a System Patch?
A System patch contains several sub-patches whose locations are determined by a file called bundle.xml in the top level directory of the patch. The sub-patches are intended for different sub-systems of a system that correspond with the OMS core and plug-in home organization.
A typical System patch format is organized as follows:
<System patch location - directory>
|_____ Readme.txt (or) Readme.html
bundle.xml
automation
|_____ apply_automation.xml
|_____rollback_automation.xml
Sub-patch1
|_____ etc
|_____config
|_____ inventory.xml
|_____ actions.xml
|_____ artifact_apply.xml
|_____ artifact_rollback.xml
|_____ files/Subpatch1 'payload'
Sub-patch2
|_____ etc
|_____config
|_____ inventory.xml
|_____ actions.xml
|_____ artifact_apply.xml
|_____ artifact_rollback.xml
|_____ files/Subpatch1 'payload'
Supported Patching Methodologies
OMSPatcher supports rolling mode only for System patches without any automation (binary-only patching through OMSPatcher). For all other artifacts, such as Metadata Registration Service (MRS) or SQL, OMSPatcher only supports complete system downtime patching operations.
Rapid Platform Update
OMSPatcher also supports {Varref: nzdt}Rapid Platform Update, which allows most of the patching process to take place while the OMS is running, significantly reducing system downtime. For more information about Rapid Platform Update, see .Rapid Platform Update
Refer to the patch README for the explicit information on supported patching methodologies.
Required OMSPatcher Parameters
OMSPatcher for the Enterprise Manager OMS will prompt for the following input parameters when performing patching operations. These parameters were determined at the time of Enterprise Manager installation.
-
Oracle WebLogic Admin Sever URL & port number
-
Oracle WebLogic Administration Server username
-
Oracle WebLogic Administration Server password
-
SYS user password
-
SYSMAN user password
Because OMSPatcher requires this input for each patching operation, OMSPatcher provides the ability to encrypt the username and password via WebLogic encryption APIs and pass this information using a property file when running OMSPatcher apply and rollback operations. The next section discusses how to create a property file.
Creating a Property File
The automated patching functionality achieved using OMSPatcher expects WebLogic Administration Server URL and credentials as an input for patching and configuration detection operations. Primarily, the WebLogic Administration server is the host that manages the Managed Server where the OMS instance is deployed. If you do not want to set the credentials every time you are prompted while patching the OMS, you can update the property file. OMSPatcher allows you to repeatedly provide the inputs using property file option.
Note:
If the OMS's are configured with virtual hostnames, you first need to set the following environment variable before executing the createkeys.sh command (Step 1).
export WLST_PROPERTIES="-Dweblogic.security.SSL.ignoreHostnameVerification=true"Prerequisites for Running OMSPatcher
Before running an OMSPatcher patching session, you must ensure the following configuration and inventory-based prerequisites are satisfied: Configuration-based conditions that have to be honored for OMS automation is given below.
-
The Enterprise Manager Software library must be configured.
-
The Oracle WebLogic Administration Server that controls the OMS instance (currently to be patched) through a managed server must be up and running.
-
Ensure that the Oracle Database, which houses the OMS Management Repository, and its listener are up and running.
-
Ensure that you have the latest version of the OMSPatcher in the OMS platform home of each host.
If you do not have the latest OMSPatcher version, follow the instructions outlined in the My Oracle Support note 13.5: How To Upgrade Enterprise Manager 13.5 Cloud Control OMSPatcher Utility to Version 13.9.5.2.0 (Doc ID 2809842.1).
-
Check your patch README to determine whether there are any specific prerequisites to be executed based on patch and patching methodologies.
Using OMSPatcher
OMSPatcher must be run from the platform home of the OMS being patched. To run OMSPatcher commands from any directory include <ORACLE_HOME_PATH>/OMSPatcher in the PATH environment variable. The ORACLE_HOME environment variable must be set as the platform home or provided using the OMSPatcher "oh" option. For example:
omspatcher apply <patch> -oh Minimum Required OMSPatcher Version: Refer to the patch README for the required version.
Ensuring You Have the Latest Version of OMSPatcher
OMSPatcher is the patching utility that executes end to end patching procedure for OMS Patches. Ensure that the latest version of OMSPatcher is available on all instances of OMS platform homes.
To check the version of OMSPatcher residing on the system, run the following command:
omspatcher versionTo get the latest OMSPatcher version, follow the instructions outlined in the My Oracle Support note 2135028.1 available at:
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=277259559046496&id=2135028.1&_afrWindowMode=0&_adf.ctrl-state=4eefxg576_200
Ensuring You Have the Latest Version of OPatch
OMSPatcher uses the OPatch utility to apply the patch. For this reason, you must ensure that you have the latest version of OPatch on all instance of OMS platform homes. To check the version of OPatch residing on the system, run the following command. Ensure to execute the command after including ORACLE_HOME/OPatch in the PATH environment variable.
opatch versionTo download the latest version of OPatch, follow the instructions outlined in the My Oracle Support note 2728285.1 available at the following location:
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id= 2728285.1
Minimum Required OPatch Version: Refer to the patch README for the required version.
Patching Quickstart
Using OMSPatcher typically involves the following phases:
1. Determining Whether Your System Meets OMSPatcher System Requirements
Run omspatcher apply -analyze
The apply -analyze command simulates an OMSPatcher apply session by running all prerequisite checks, when possible, without making changes to the system (either bits or configurations). This command does not apply the patch.
See "Prerequisites for Running OMSPatcher" for additional information.
2. Determining What System Patches Currently Exist on Your System
Run omspatcher lspatches
See "lspatches" for more information.
3. Obtaining Patches from My Oracle Support (MOS)
OMSPatcher requires that the required platform or plug-in System patches be obtained from My Oracle Support and downloaded to the OMS instance on which OMSPatcher is to be run.
See "My Oracle Support: Searching for Patches" for more information.
4. Applying a Patch
Run omspatcher apply <patch>
The apply command applies all patches within a specified System patch to the platform home from which omspatcher command is run.
See "Running omspatcher apply" for more information.
5. Deinstalling Individual Sub-patches of a System Patch
Run omspatcher rollback -id <list of comma separated sub-patches of System patch>
Note:
For a complete list of sub-patches of the System patch, refer to the patch README.
If, after applying the patch, the system is not stable, the most likely cause is the patch itself. Contact Oracle Support. They will recommend that you remove the patch using the omspatcher rollback command.
See "Running omspatcher rollback" for more information.
My Oracle Support: Searching for Patches
The first step in the patching process is to determine what patches you need from My Oracle Support (MOS). MOS is the single source of truth for patching. You can access MOS at the following location:
https://support.oracle.com
Once you have logged in, you have access to interactive support tools and information that simplify searching for and obtaining the requisite patches for your Oracle environment. .
My Oracle Support contains many features and capabilities that are grouped under tabs across the top of the application. Of primary interest is the Patches and Updates tab. From this tab you can search for the patches based on the OMS patch area (core, plug-in, or combination).
Checking System Prerequisites
Note:
To run OMSPatcher commands, ensure that <ORACLE_HOME>/OMSPatcher is included in the PATH environment variable.
To make sure all prerequisite checks pass and no errors occur during the OMSPatcher patching session, Oracle recommends running the following commands on each OMS instance (in your OMS system).
omspatcher apply <PATCH_LOC> -analyzeMust be run from the System patch location (for apply operations)
Note:
OMS systems need not be shut down when running apply -analyze.
Note:
Check the Patch README and the instructions given for chosen patching methodologies.
OR
omspatcher rollback -analyze -id <comma (,) separated list of sub-patches to be rolled back for System patch>
Note:
In order to roll back all sub-patches together, all sub-patches should be from same system patch.
Example 5-1 OMSPatcher rollback -analyze output
$ OMSPatcher/omspatcher rollback -id 1111140 -analyze
OMSPatcher Automation Tool
Copyright (c) 2017, Oracle Corporation. All rights reserved.
OMSPatcher version : 13.9.5.3.0
OUI version : 13.9.4.0.0
Running from : /scratch/em/oms
Log file location : /scratch/em/oms/cfgtoollogs/omspatcher/opatch2022-03-22_09-54-14AM_1.log
Calling the rollback
Starting OMSRollbackSession at
OMSPatcher log file: /scratch/em/oms/cfgtoollogs/omspatcher/SystemPatch/omspatcher_2022-03-22_09-54-15AM_analyze.log
Please enter OMS weblogic admin server URL(t3s://emcore008.subnet1rg2phxsu.emdevinfraphx1.oraclevcn.com:7102):>
Please enter OMS weblogic admin server username(weblogic):>
Please enter OMS weblogic admin server password:>
Enter SYS Password :
Sub-patch(es) " 1111140 " are part of the OMS System patch.
Oracle Home: /scratch/em/oms, Sub-patch(es): [1111143, 1111140]
Do you want to rollback sub-patch(es) "1111140" only? [y|n]
y
User Responded with: Y
Configuration Validation: Success
Running rollback prerequisite checks for patch(es) "1111140" and Oracle Home "/scratch/em/oms"...
Sub-patch(es) "1111140" are successfully analyzed for Oracle Home "/scratch/em/oms"
Complete Summary
================
All log file names referenced below can be accessed from the directory "/scratch/em/oms/cfgtoollogs/omspatcher/2022-03-22_09-54-14AM_SystemPatch_1111112_1"
Prerequisites analysis summary:
-------------------------------
The following sub-patch(es) are rollbackable:
Featureset Sub-patches Log file
---------- ----------- --------
oracle.sysman.top.oms 1111140 1111140_opatch2022-03-22_09-54-24AM_1.log
Log file location: /scratch/em/oms/cfgtoollogs/omspatcher/SystemPatch/omspatcher_2022-03-22_09-54-15AM_analyze.log
OMSPatcher succeeded.
Note:
Once the analysis finishes, you can refer to the OMSPatcher log to see what steps would be executed by OMSPatcher in non -analyze mode. The log file contains references to the HTML and text output file HTML containing detailed steps.
Running omspatcher apply
Once you have downloaded the patch, see the patch README for explicit patch details and instructions on applying the patch. You can find the README at the following location
<System patch location>/README.txt (or) README.html
As you step through the patching operations in the README, running omspatcher apply (depending on the configuration that is patched, primary or standby) will generate a custom, environment-specific version of the README for patching operations for the primary site multi-OMS or standby site OMS systems. For a primary site single OMS system, running omspatcher apply will perform patching and deployment operations.
On your local OMS instance, run the following command from the top level System patch directory:
omspatcher apply <patch>
Note:
Unlike omspatcher analyze, you should not run omspatcher apply on every OMS instance. OMSPatcher will either execute all patching and deployment operations, or will generate environment-specific steps that include complete configuration aspects of the System.
In a multi-OMS UNIX system, the primary OMS is patched using the omspatcher apply command. Upon completing the primary OMS patching, the OMSpatcher utility will submit a job to patch additional OMS instances. The job name will appear in the terminal from which the OMSpatcher utility is executed on the primary OMS server. The status of the multi-OMS patching job can be verified through the Enterprise Manager console or via emcli command. For Windows multi-OMS systems, OMSPatcher will generate a bash script that can be run on all OMSes except the primary OMS.
There are two ways in which patches are applied on a multiple OMS setup.
- Automated: A job is automatically submitted that deploys the patches (Linux systems) on each additional OMS.
- Manual: OMSPatcher provides auto-generated bash scripts that can be run on all the OMSes except the primary OMS. (UNIX and Windows based systems).
Applying a System Patch
Note:
Since omspatcher is located in ‘$ORACLE_HOME/OMSPatcher’, ensure that the directory is included in the path before running the commands.-
Execute OMSPatcher for the System Patch.
For example,OMSPatcher/omspatcher apply /tmp/1111141/ OMSPatcher Automation Tool Copyright (c) 2021, Oracle Corporation. All rights reserved. OMSPatcher version : <latest OMSPatcher version> OUI version : 13.9.4.0.0 Running from : $ORACLE_HOME Log file location : $ORACLE_HOME/cfgtoollogs/omspatcher/opatch2021-03-25_21-55-52PM_1.log OMSPatcher log file: $ORACLE_HOME/cfgtoollogs/omspatcher/1111141/omspatcher_2021-03-25_21-55-57PM_deploy.log Please enter OMS weblogic admin server URL(t3s://den01mjo.mycompany.com:7102):> Please enter OMS weblogic admin server username(weblogic):> Please enter OMS weblogic admin server password:> Configuration Validation: Success Running apply prerequisite checks for sub-patch(es) "1111141" and Oracle Home "$ORACLE_HOME"... Sub-patch(es) "1111141" are successfully analyzed for Oracle Home "$ORACLE_HOME" To continue, OMSPatcher will do the following: [Patch and deploy artifacts] : Apply sub-patch(es) [ 1111141 ] Register MRS artifact "targetPatchingImplRegistration" Do you want to proceed? [y|n] y User Responded with: Y Applying sub-patch(es) "1111141" Please monitor log file: /u01/yourinst/ap_omshome/cfgtoollogs/opatch/opatch2021-03-25_21-55-56PM_1.log Registering service "targetPatchingImplRegistration" with register file "/u01/yourinst/ap_omshome/sysman/metadata/targetPatchingImplRegistration/RegisterWrongOHTargetForPatching.xml" for plugin id as "core"... Please monitor log file: /u01/yourinst/ap_omshome/cfgtoollogs/omspatcher/2021-03-25_21-55-52PM_SystemPatch_1111141_1/emctl_register_targetPatchingImplRegistration_2021-03-25_21-57-51PM.log Complete Summary ================ All log file names referenced below can be accessed from the directory "/u01/yourinst/ap_omshome/cfgtoollogs/omspatcher/2021-03-25_21-55-52PM_SystemPatch_1111141_1" Patching summary: ----------------- Binaries of the following sub-patch(es) have been applied successfully: Featureset Sub-patches Log file ---------- ----------- -------- oracle.sysman.top.oms_13.5.0.0.0 1111141 1111141_opatch2021-03-25_21-55-56PM_1.log Deployment summary: ------------------- The following artifact(s) have been successfully deployed: Artifacts Log file --------- -------- MRS-targetPatchingImplRegistration emctl_register_targetPatchingImplRegistration_2021-03-25_21-57-51PM.log Log file location: /u01/yourinst/ap_omshome/cfgtoollogs/omspatcher/1111141/omspatcher_2021-03-25_21-55-57PM_deploy.log OMSPatcher succeeded. -
Run
omspatcher lspatchescommand to list all the sub-patches applied in Step 1.Syntax:
omspatcher lspatches | grep "bp_id"For example,************omspatcher Trace for reference $omspatcher lspatches | grep 30684860 oracle.help.ohw.rcf/12.2.1.3.0 Core N/A 30684860 ADF BUNDLE PATCH 12.2.1.3.0(ID:191219.0902.S) oracle.jrf.adfrt.javatools/12.2.1.3.0 Core N/A 30684860 ADF BUNDLE PATCH 12.2.1.3.0(ID:191219.0902.S) oracle.jrf.adfrt/12.2.1.3.0 Core N/A 30684860 ADF BUNDLE PATCH 12.2.1.3.0(ID:191219.0902.S) oracle.help.ohw.share/12.2.1.3.0 Core N/A 30684860 ADF BUNDLE PATCH 12.2.1.3.0(ID:191219.0902.S) oracle.jrf.adfrt.help/12.2.1.3.0 Core N/A 30684860 ADF BUNDLE PATCH 12.2.1.3.0(ID:191219.0902.S)Note:
The last column lists all the sub-patches applied with the Release Update/Bundle Patch.
Running omspatcher rollback
See the patch README for explicit patch details and instructions on deinstalling the patch. You can find the README at the following location
<System patch location>/README.txt (or) README.html
As you step through the patch deinstallation operations in the README, running omspatcher rollback (depending on the configuration that is patched, primary or standby) will generate a custom, environment-specific version of the README for patching operations for the primary site multi-OMS or standby site OMS systems. For a primary site single OMS system, running omspatcher rollback will perform the deinstallation operations.
On your local OMS instance, run the following command from the top level System patch directory:
omspatcher rollback -id <list of comma separated sub-patches of System patchNote:
-
Unlike
omspatcher analyze, you should not execute the omspatcher rollback command on every OMS instance. OMSPatcher will either execute all patching and deployment operations, or will generate environment-specific steps that include complete configuration aspects of the System. -
The list of sub-patches within the System patch can be retrieved from patch README.
The list of sub-patches listed in System patch README may differ from the patches that are actually installed. During System patch installation, some sub-patches may be skipped (not installed).
For a multi-OMS UNIX system, OMSPatcher generates bash scripts for execution, one per OMS instance; follow the instructions given by omspatcher to find those scripts. For Windows multi-OMS systems, OMSPatcher will generate customized patching instructions/commands for the environment in text and HTML formats; administrators must execute these instructions to patch the various OMSs.
There are two ways in which patches are applied on a multiple OMS setup.
- Automated: A job is automatically submitted that deploys the patches (Linux systems) on each OMS.
- Manual: OMSPatcher provides auto-generated bash scripts (one per OMS instance) for UNIX based systems. For Windows, it only provides context-sensitive steps (text and HTML). For both cases, the administrator needs to follow the steps given by OMSPatcher.
Running omspatcher lspatches
After the patch is applied or rolled back, you can run the omspatcher lspatches command to generate a comprehensive Component type - patches map of the OMS homes and installed patches.
$omspatcher lspatches
OMSPatcher Automation Tool
Copyright (c) 2017, Oracle Corporation. All rights reserved.
OMSPatcher version : <latest_OMSPatcher_version>
OUI version : 13.9.4.0.0
Running from : $ORACLE_HOME
Log file location : $ORACLE_HOME/cfgtoollogs/omspatcher/opatch2023-02-15_11-56-30AM_1.log
Component Name/Version Component Type System Patch (Sub)-Patches Patch Description
------------------------ ------------- ------------- -------------- ------------------
oracle.com.fasterxml.jackson.jaxrs.jacks Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
on.jaxrs.base/2.9.9.0.0
oracle.jrf.iau/12.2.1.4.0 Core N/A 31666198 OPSS Bundle Patch 12.2.1.4.200724
oracle.wls.common.cam.wlst/12.2.1.4.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
oracle.ohs2/12.2.1.4.0 Core N/A 31808404 OHS (NATIVE) BUNDLE PATCH 12.2.1.4.200826
oracle.com.fasterxml.jackson.jaxrs.jacks Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
on.jaxrs.json.provider/2.9.9.0.0
oracle.com.fasterxml.jackson.core.jackso Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
n.databind/2.9.9.0.0
oracle.wls.jrf.tenancy.common.sharedlib/ Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
12.2.1.4.0
oracle.jrf.adfrt/12.2.1.4.0 Core N/A 32458315 ADF BUNDLE PATCH 12.2.1.4.210203
oracle.com.fasterxml.jackson.module.jack Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
son.module.jsonschema/2.9.9.0.0
oracle.jrf.toplink/12.2.1.4.0 Core N/A 32412974 One-off
oracle.wls.jrf.tenancy.ee.only.sharedlib Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
/12.2.1.4.0
oracle.webcenter.wccore/12.2.1.4.0 Core N/A 31818221 One-off
oracle.log4j.log4j/2.11.1.0.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
oracle.xdk.jrf.xmlparserv2/12.2.1.4.0 Core N/A 26626168 One-off
oracle.fmwconfig.common.wls.shared.inter Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
nal/12.2.1.4.0
oracle.com.fasterxml.jackson.module.jack Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
son.module.jaxb.annotations/2.9.9.0.0
oracle.sysman.vi.oms.plugin/13.5.1.0.0 Plugin 1111112 1111140 EM nZDT Patch for TargetPrivs
oracle.com.fasterxml.jackson.core.jackso Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
n.core/2.9.9.0.0
oracle.opss.wls/12.2.1.4.0 Core N/A 31708760 One-off
oracle.org.bouncycastle.bcprov.jdk15on/1 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
.60.0.0.0
oracle.wls.core.app.server/12.2.1.4.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
oracle.wls.security.core.sharedlib/12.2. Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
1.4.0
oracle.wls.shared.with.cam/12.2.1.4.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
oracle.org.bouncycastle.bcprov.ext.jdk15 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
on/1.60.0.0.0
oracle.coherence/12.2.1.4.0 Core N/A 122146 Bundle patch for Oracle Coherence Version 12.2.1.4.6
oracle.xdk.jrf.jaxp/12.2.1.4.0 Core N/A 26626168 One-off
oracle.wls.libraries/12.2.1.4.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
oracle.com.fasterxml.jackson.dataformat. Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
jackson.dataformat.xml/2.9.9.0.0
oracle.opss.core/12.2.1.4.0 Core N/A 31666198 OPSS Bundle Patch 12.2.1.4.200724
N/A 31708760 One-off
oracle.webservices.wls/12.2.1.4.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
oracle.wls.security.core/12.2.1.4.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
oracle.sysman.top.oms/13.5.0.0.0 Core 1111112 1111143
oracle.sysman.rcu/12.2.1.4.0 Core N/A 30152128 One-off
oracle.org.bouncycastle.bcpkix.jdk15on/1 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
.60.0.0.0
oracle.webservices.base/12.2.1.4.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
oracle.com.fasterxml.jackson.core.jackso Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
n.annotations/2.9.9.0.0
oracle.wls.evaluation.database/12.2.1.4. Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
0
oracle.wls.admin.console.en/12.2.1.4.0 Core N/A 32253037 WLS PATCH SET UPDATE 12.2.1.4.201209
NOTE: N/A indicates that the subpatch mentioned in the Subpatches column was applied as a one-off patch and not as part of any system patch.
OMSPatcher has saved inventory details for the above component at below location.
"/$ORACLE_HOME"
For more details on installed patch(es), Please do "$ORACLE_HOME/OPatch/opatch lsinventory -details"
OMSPatcher succeeded.Note:
The last column lists all the sub-patches applied with the Release Update/Bundle Patch.Running omspatcher version
To determine the version numbers of the various OMSPatcher utilities (OPlan, OsysModel) that reside on your system, you can run omspatcher version.
bash-3.2$ omspatcher version
OMSPatcher Version: <latest OMSPatcher version>
OPlan Version: 12.1.0.2.2
OsysModel build: Wed Mar 21 18:20:48 PDT 2018
Running Rapid Platform Update Commands
Rapid Platform Update introduces the following new commands:
deploy: Performs pre-downtime MRS and SQL execution.update: Perform the downtime activity and complete the patching and bring up the OMS.rollback deploy: Reverts the system back to its original state prior to a failed patching attempt.status: Returns the status of the Oracle Home patching.resume: Resumes the previous failed operation
For more information about Rapid Platform Update usage and commands, see Rapid Platform Update.
Patching a Standby OMS System
If you have configured a standby OMS for High Availability, refer to the chapter on "Enterprise Manager Disaster Recovery" and the appendix on Standby OMSs Using Standby WebLogic Domain" both of which can be found in the Oracle Enterprise Manager Advanced Installation and Configuration Guide.
Patching with Non-SYS User (Admin User)
Starting with Enterprise Manager 13c Release 5 Update 15 (13.5.0.15) or higher, you can patch the OMS using a non-SYS admin user. Oracle provides the option to perform the patching of the OMS using another user, a less-privileged Management Repository administrator user, also known as non-SYS user.
Since security is a growing concern, organizations continue to lock privileged credentials like the SYS user and Enterprise Manager administrators are having challenges in getting the SYS user account that is required for patching, plug-in deployment and install activities. Patching with the non-SYS user provides a solution with a more secure and compliant process for the patching and plug-in deployment activities.
- Patching/applying the Release Update using the non-SYS user is supported
starting with Enterprise Manager 13c Release 5 Update 15 (13.5.0.15) or higher.
Ensure the corresponding OMSPatcher version is downloaded from My Oracle Support as per the instructions from the patch README file.
- Once the OMSPatcher zip file is downloaded, update the OMSPatcher directory in the OMS
home and ensure the version number is the same as the one updated in the patch readme
file.
This step confirms that the
createLcmUserUtlfolder was created in the OMS home. - OMSPatcher usage: You are familiar with OMSPatcher usage. Before proceeding, review Using OMSPatcher.
- Create the non-SYS user.
Prerequisite:
-
Non-SYS user naming convention: When creating the non-SYS user, ensure that the selected name has the
SYSMAN_prefix as part of the username.For example:
SYSMAN_ADMIN -
Windows Environment: Download the patch 33053642 from My Oracle Support and apply it to the Oracle home before proceeding to create the non-SYS user.
Patch 33053642 installs the Repository Create Utility (RCU) component for Windows.
You can create the new non-SYS user (admin user) in silent or interactive mode.- Interactive mode
To create the non-SYS user in interactive mode, do the following:
- Create the non-SYS user using the
createLcmUserUtlby running the following:$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/OMSPatcher/createLcmUserUtl/createLCMUser.pl -oh <Oracle_Home_location>- All values provided interactively must be string characters.
- The value of the non-SYS user name must start with the
prefix
SYSMAN_. For example:SYSMAN_ADMIN. $ORACLE_HOMEis the OMS home directory.- Perl path: You need to use the Oracle_Home perl path to run
the
createLcmUserUtlutility. - Only one non-SYS user can be created in the Enterprise Manager environment.
- Switch to SYS user is not allowed once the non-SYS user is used for the Enterprise Manager installation, patching or deploying plug-ins.
For example:/u01/app/oracle/mw135/perl/bin/perl /u01/app/oracle/mw135/OMSPatcher/createLcmUserUtl/createLCMUser.pl -oh /u01/app/oracle/mw135 Enter dbuser name : SYSMAN_ADMIN Enter dbuser password : WelcomepwdFrom the above example:
$ORACLE_HOMEvalue is/u01/app/oracle/mw135SYSMAN_ADMINandWelcomepwdare the values entered by the user interactively.SYSMAN_ADMINdb user is the new non-SYS user andWelcomepwdis the non-SYS user password.
- Create the non-SYS user using the
- Silent modeTo create the non-SYS user in silent mode, do the following:
- Create a property file (text file) with the following entries:
sysPassword=<SYS_DATABASE_USER_PASSWORD> dbUser=<NON-SYS_USER> #This user will get created in the repository database dbPassword=<NON-SYS_USER_PASSWORD>- All values must be string characters.
- The value of the non-SYS user must start with the prefix
SYSMAN_. For example:SYSMAN_ADMINorSYSMAN_test. - Only one non-SYS user can be created in the Enterprise Manager environment.
- Switch to SYS user is not allowed once the non-SYS user is used for the Enterprise Manager installation, patching or deploying plug-ins.
For example:sysPassword=Welcomepwd dbUser=SYSMAN_ADMIN dbPassword=WelcomeadminpasswordSave the file using any preferred name. For example:
non_sys_user.properties. - Create the non-SYS user using the
createLcmUserUtland the property file from step a by running the following:$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/OMSPatcher/createLcmUserUtl/createLCMUser.pl -oh <Oracle_Home_location> -silent –property_file <propertyfile_location>For example:/u01/app/oracle/mw135/perl/bin/perl /u01/app/oracle/mw135/OMSPatcher/createLcmUserUtl/createLCMUser.pl -oh /u01/app/oracle/mw135 -silent –property_file /u01/app/oracle/mw135/non_sys_user.properties- For Windows, run the
createLcmUserUtlutility from the$<ORACLE_HOME>. - Use the
-silentargument. $ORACLE_HOMEis the OMS home directory and its value is/u01/app/oracle/mw135- You need to use the Oracle home perl path to run the
createLcmUserUtlutility. - Only one non-SYS user can be created in the Enterprise Manager environment.
- Switch to SYS user is not allowed once the non-SYS user is used for the Enterprise Manager installation, patching or deploying plug-ins.
- For Windows, run the
- Create a property file (text file) with the following entries:
Note:
The non-SYS admin user can be created at any time. Once you start using the non-SYS admin user for the configuration or patching of the OMS, you cannot switch back to use SYS as an admin user to perform any of those operations.If the non-SYS admin user was created, but for some reason, you decide not to use that non-SYS user to apply the patch anymore, you can enter SYS as the admin user when applying it.
-
- Apply the patch (Release Update)
Once the non-SYS user is created, you can proceed to apply the patch available from My Oracle Support which must be Enterprise Manager 13c Release 5 Update 15 (13.5.0.15) or higher version.
During the patching process, provide the non-SYS user and password details from step 1 when the Release Update (patch) requests to "
Enter DB user" and"Enter DB password".For information about OMSPatcher, see Using OMSPatcher. For details of the
applycommand syntax, see Apply.Note:
Silent Mode - If you are patching Enterprise Manager 13c Release 5 Update 15 (13.5.0.15) or higher, the property file must have the following entries:AdminConfigFile=<String> AdminKeyFile=<String> Sysman_pwd=<SYS_PASSWORD> dbUser=<NON-SYS_USER> dbPassword=<NON-SYS_USER_PASSOWORD>For example:AdminConfigFile=<String> AdminKeyFile=<String> Sysman_pwd=<SYS_PASSWORD> dbUser=SYSMAN_ADMIN dbPassword=WelcomeadminpasswordUse the above property file when patching an environment that has already created the non-SYS user (instead of using SYS) as the Management Repository admin user.
OMSPatcher Command Syntax
This section provides a comprehensive listing and description of all OMSPatcher commands used to patch an OMS.
Note:
OMSPatcher commands must be run from the OMS Middleware home.
OMSPatcher Commands
The OMSPatcher commands are run from the OMS Middleware home out of the OMSPatcher directory. The Middleware home must be set as $ORACLE_HOME. In the following generic example, an OMSPatcher command is run from a Middleware home.
omspatcher apply <PATH_TO_PATCH_DIRECTORY>
where <PATH_TO_PATCH_DIRECTORY> is the full path to the System patch top level directory.
You can view online help for any command (except version) by specifying the -help option.
[COMMENT: Dev needs to supply new -help output that includes the new command/options]
OMSPatcher Automation Tool
Copyright (c) 2021, Oracle Corporation. All rights reserved.
Usage: omspatcher [ -help ] [ -analyze ] [ command ]
command := apply
rollback
checkApplicable
lspatches
version
saveConfigurationSnapshot
<global_arguments> := -help Displays the help message for the command.
-analyze Print the actions, steps to be performed without any execution.
example:
'omspatcher -help'
'omspatcher apply -help'
'omspatcher rollback -help'
'omspatcher checkApplicable -help'
'omspatcher lspatches -help'
'omspatcher saveConfigurationSnapshot -help'
OMSPatcher succeeded.omspatcher consists of the following primary commands.
-
apply
-
rollback
-
checkapplicable
-
saveConfigurationSnapshot
-
lspatches
-
version
Apply
Apply a System patch to OMS instance homes. You must specify the patch location or the current directory will be used as the patch location.
Note:
OMSPatcher must be run from the platform home. ORACLE_HOME environment variable must be set as the platform home or provided using the –oh option.
You must run the Apply command directly from the System patch location.
When running omspatcher apply, you will be prompted the following:
-
WebLogic Admin Server URL of the primary OMS (or standby OMS)
-
Username and Password
Silent interaction is supported by using the silent and property_file options.The standby option should be used if a stand by OMS system is patched. OMSPatcher can pass 'x=y' properties through the command line. See Table 5-2.
Syntax
omspatcher apply <System patch location>
[-custCertPath <Path to customer optional certificate>]
[-jre <Path to JRE>] [-nonrolling]
[-invPtrLoc <Path to oraInst.loc>]
[-property_file <Path to property file>]
[-analyze] [-silent] [-oh <Platform home path>]
[-standby]
Parameters
<System patch location>
Path to the location of the patch. If the patch location is not specified, then the current directory is taken as the patch location. The patch can only be a System patch.
Apply Command Options
Table 5-1 Apply
| Option | Description |
|---|---|
|
jre |
This option tells OMSPatcher to use JRE (java) from the specified location instead of the default location under Oracle Home. |
|
invPtrLoc |
Used to locate the oraInst.loc file. Needed when the installation used the -invPtrLoc flag. This should be the path to the oraInst.loc file. |
|
property_file |
The user-defined property file for OMSPatcher to use. The path to the property file should be absolute. The keys for 'omspatcher' are: 'AdminConfigFile' - Encrypted file for Admin Server user of OMS instance domain. 'AdminKeyFile' - Encrypted file for Admin Server password of OMS instance domain. 'AdminServerURL' - Admin Server URL of OMS instance domain. (Example: t3s://<host address>:<port number>) The Key, value pair is of the format 'x=y' where 'x' is omspatcher understood key and each pair is separated by new line in the property file. This option is typically used for silent operations. This option is very useful for silent mode of 'omspatcher' invocation. In order to create encrypted files for WebLogic admin server username & password. Please use
NOTE: For Windows, please make sure that directories and files in the path are separated by "\\" in the property file. |
|
analyze |
Just prints out the actions without any configuration/binary change through |
|
silent |
This suppresses any user-interaction. |
|
oh |
The location of EM platform home. This overrides the ORACLE_HOME environment variable. |
|
custCertPath |
This option tells OMSPatcher to use the certificate from the specified location. |
|
nonrolling |
Apply and deploy the patch in non-rolling fashion, provided it is supported by the patch. |
|
standby |
This option should be used for standby OMS patching operations. |
Apply Command Properties
Table 5-2 Apply Properties
| Option | Description |
|---|---|
|
OMSPatcher.OMS_DISABLE_HOST_CHECK=true |
Used to disable host verification check for WebLogic admin server. Please set this property to true if your OMS configuration is based on virtual host. |
|
OMSPatcher.OMS_USER=<installed OMS user> |
Use this property if OMSPatcher is not able to get the installed OMS administrator name by itself. This switch is applicable only for Windows. |
|
OMSPatcher.OMS_SCRIPTS_DIR=<existing directory> |
This switch is applicable only for UNIX systems. By providing an existing directory, the bash scripts produced by OMSPatcher for multi-OMS are copied to a newly created time stamped sub-directory under the directory specified by the administrator. This would help OMS administrator to execute the scripts from pre-determined shared location, if any, rather than manual scripts copied to each OMS box. |
Rollback
Roll back sub-patches of a System patch from OMS instance home. Administrator specifies the sub-patch IDs of the System patch. You can obtain the sub-patch IDs by running the omspatcher lspatches command. See "Running omspatcher lspatches".
Important: OMSPatcher must be run from the Middleware home. ORACLE_HOME environment variable must be set as platform home or provided via the –oh option.
When running omspatcher rollback, you will be prompted the following:
-
WebLogic Admin Server URL of the primary OMS (or standby OMS)
-
Username and Password
Silent interaction is supported by using the silent and property_file options.The standby option should be used if a stand by OMS system is patched. OMSPatcher can pass 'x=y' properties through the command line. See Table 5-2.
Syntax
omspatcher rollback -id <sub patches ID of System patch>
[-custCertPath <Path to customer optional certificate>]
[-idFile <file contains list of sub-patch IDs of System patch>]
[-invPtrLoc <Path to oraInst.loc>
[-jre <LOC>] [-silent] [-nonrolling]
[-property_file <path to property file>]
[-analyze] [-oh <Platform home path>]
[-standby]Parameters
Sub patch IDs for the System patch to be rolled back. If you want to rollback a whole System patch, the ids of all sub-patches of that System patch must be specified.
Rollback Options
Table 5-3 Rollback
| Option | Description |
|---|---|
|
id |
Use |
|
idFile |
File that contains the list of sub-patch IDs of a System patch. |
|
invPtrLoc |
Used to locate the oraInst.loc file. Needed when the installation used the invPtrLoc flag. This should be the path to the oraInst.loc file. |
|
jre |
This option tells omspatcher to use JRE (java) from the specified location instead of the default location under Oracle Home. |
|
silent |
This option suppresses any user-interaction. |
|
nonrolling |
Roll back and deploy the patch in non-rolling fashion, provided it is supported by the patch. |
|
property_file |
The administrator defined property file for omspatcher to use. The path to the property file should be absolute. The keys for 'omspatcher' are: 'AdminConfigFile' - Encrypted file for Admin Server user of OMS instance domain. 'AdminKeyFile' - Encrypted file for Admin Server password of OMS instance domain. 'AdminServerURL' - Admin Server URL of OMS instance domain. (Example: t3s://<host address>:<port number>) The key value pair is of the format 'x=y' where 'x' is omspatcher understood key and each pair is separated by new line in the property file. This option is typically used for silent operations. This option is very useful for silent mode of 'omspatcher' invocation. In order to create encrypted files for WebLogic admin server username & password, Please use NOTE: For Windows, ensure that directories and files in the path are separated by "\\" in the property file. |
|
analyze |
Displays out the actions without any configuration/binary change through 'omspatcher'. |
|
custCertPath |
This option tells OMSPatcher to use the certificate from the specified location. |
|
oh |
The location of EM platform home. This overrides the ORACLE_HOME environment variable. |
|
standby |
This option should be used for standby OMS patching operations. |
Rollback Command Properties
Table 5-4 Rollback Properties
| Option | Description |
|---|---|
|
OMSPatcher.OMS_DISABLE_HOST_CHECK=true |
Used to disable host verification check for WebLogic admin server. Please set this property to true if your OMS configuration is based on virtual host. |
|
OMSPatcher.OMS_USER=<installed OMS user> |
Use this property if OMSPatcher is not able to get the installed OMS administrator name by itself. This switch is applicable only for Windows. |
lspatches
Displays the list of patches applied to the OMS home. It will show the component Name/Version, Component Type, System patch, Sub-patch and patch description where patch has been applied. Please note that OMSPatcher will be used to apply only system patches. However the OMS can have one-off patches which would have already been applied at the time of the Enterprise Manager installation. OMSPatcher provides information about whether the patch is a system patch or one-off patch and, if it is the system patch, then it will also show all other patches that are part of that system patch.
Syntax
omspatcher lspatches [ -invPtrLoc <Path to oraInst.loc> ] [-jre <LOC> ] [-oh]
Options
Table 5-5 lspatches
| Option | Description |
|---|---|
|
jre |
This |
|
invPtrLoc |
The |
|
oh |
The location of Middleware home. This overrides the ORACLE_HOME environment variable. |
version
The version command shows the current version number of the OPatch utility, dependent OPlan version, and the osysmodel version.
Important: OMSPatcher must be run from the Middleware home.
Syntax
omspatcher version [-invPtrLoc <Path to oraInst.loc>]
[-jre <LOC>]
[-oh <ORACLE_HOME>]
[-help] [-h]Options
The following table describes the options available for the version command.
Table 5-6 version Command Options
| Option | Description |
|---|---|
|
-invPtrLoc |
The |
|
-jre |
This |
|
-oh |
The |
checkApplicable
The checkApplicable command performs prerequisite binary checks on the OMS platform home and plug-in homes to determine the applicability of a System patch and/or the whether sub-patches of the System patch can be rolled back.
Syntax
omspatcher checkApplicable
[-id <singleton or System Patch ID to be rolled back>]
[-custCertPath <Path to customer optional certificate>]
[-invPtrLoc <Path to oraInst.loc>]
[-jre <LOC>]
[-ph <System patch that is to be installed>] [-silent]
Options
The following table describes the options available for the checkApplicable command.
Table 5-7 checkApplicable Command Options
| Option | Description |
|---|---|
|
id |
This option can be used to specify the sub-patch IDs that are to be rolled back from the OMS platform home or plug in homes. |
|
invPtrLoc |
Used to locate the |
|
jre |
This option tells OMSPatcher to use JRE (java) from the specified location instead of the default location under Oracle Home. |
|
ph |
This option can be used to specify the path to the patch location. The input must be a System patch location. |
|
silent |
This suppresses any user-interaction. |
|
custCertPath |
This option tells OMSPatcher to use the certificate from the specified location. |
saveConfigurationSnapshot
The saveConfigurationSnapshot command generates configuration a snapshot for the primary OMS (along with OMS repository) and saves it to an XML file that can be read by OMSPatcher.
If file is not specified, it will be saved to a default file (configData.xml) at the following location
ORACLE_HOME/cfgtolllogs/omspatcher/sysconfig/configData.xml
When running the saveConfigurationSnapshot command, you will be prompted for the following:
-
WebLogic Admin Server URL of the primary OMS
-
Username and password
You can run the command in silent mode (suppress user interaction) via the silent and property_file options.
This command must be run from an OMS instance belonging to the primary OMS system. If the OMS configuration is running on a virtual host, you must set the OMSPatcher.OMS_DISABLE_HOST_CHECK=true option from the command line.
Syntax
omspatcher saveConfigurationSnapshot
[-configFile <File to save configuration snapshot> ]
[-oh <ORACLE_HOME> ]
[-invPtrLoc <Path to oraInst.loc> ]
[-jre <LOC> ]
[-silent ]
[-property_file <path to file> ]
Options
The following table describes the options available for the version command.
Table 5-8 saveConfigurationSnapshot Command Options
| Option | Description |
|---|---|
|
configFile |
Enables OPatch to write the configuration for the specified product to an XML file. The XML file can only be recognized by Oracle System Model APIs and accessed through via the Enterprise Manager SDK. |
|
oh |
Specifies the Oracle home to be worked on. The Oracle Home specified takes precedence over the environment variable ORACLE_HOME. |
|
invPtrLoc |
Used to locate the oraInst.loc file. Needed when the installation used the -invPtrLoc flag. This should be the path to the oraInst.loc file. |
|
jre |
Instructs OMSPatcher to use JRE (java) from the specified location instead of the default location under Oracle Home. |
|
silent |
Suppresses any user-interaction. |
|
property_file |
The user-defined property file for OMSPatcher to use. The path to the property file must be absolute. The keys for 'OMSPatcher' are:
The Key, value pair is of the format 'x=y' where 'x' is an OMSPatcher understood key and each pair is separated by newline in the property file. The In order to create encrypted files for a WebLogic Admin Server username & password, run the following script:
(createKeys.cmd for Windows) to obtain the files and load them through a custom file using the property_file option. NOTE: For Windows, maker sure that directories, files in the path are separated by "\\" in the property file. |
Rapid Platform Update
Patching can be a time consuming and error prone activity. This results in high administrative costs due to the required downtime and interrupted application monitoring. Rapid Platform Update patching automates many of the tasks required for patching and reduces the risk of human error. It also minimizes OMS downtime while applying patches for existing OMS(s), thus providing you with more scheduling flexibility when applying patches.
Rapid Platform Update allows most of the patching process (deploy) to take place while the OMS is running: System downtime is significantly reduced. Not having the OMS down for extended periods provides benefits such as continued target monitoring and critical alerting for your business-critical applications during planned maintenance.
Rapid Platform Update, while automating much of the patching process, still provides you with the flexibility to take the system down to perform the update during a convenient maintenance window.
To view a brief video explaining Rapid Platform Update, see Oracle Enterprise Manager agile and smart patching with Rapid Platform Update.
Prerequisites
Before running an OMSPatcher patching session, you must ensure the following configuration and inventory-based prerequisites are satisfied: Configuration-based conditions that have to be honored for OMS automation is given below.
- Repository DB should be at a minimum of 19c with RU12 or higher.
- Important: The existing Enterprise Manager OMS should be Oracle Enterprise Manager 13c Release 5 Update 3 (RU3) or higher to apply release updates in Rapid Platform Update mode.
- The Enterprise Manager Software library must be configured.
- The Oracle WebLogic Administration Server that controls the OMS instance (currently to be patched) through a managed server must be up and running.
- Ensure that the Oracle Database, which houses the OMS Management Repository, and its listener are up and running.
- Ensure that you have the latest version of the OMSPatcher in the OMS platform home of each host.
- Ensure that you have the latest version of the OPatch in the OMS platform home of each host.
- Ensure there is a 25GB of free space available on the same file system as the OMS. This space is used for cloning the OMS home.
- The OMS Base directory should be owned by the same user as the OMS. Example: If /u01/app/OMS is the OMS_HOME, /u01/app should be owned by the same user as the OMS.
- It is recommended to backup the repository DB during the “omspatcher update” operation where the OMS downtime is initiated. We recommend using a restore point for backing up the repository DB as this will minimize the downtime.
- Admin server password (weblogic password) and repository DB sys password are needed for patching.
- For OMS installed on windows, ensure that the one off patch 33053642 is applied on the OMS.
- While patching Multi OMS environment, make sure:
- The patch is staged on a shared mount point, preferably the software library.
- The central agents on the additional OMSs are up and running.
- Check your patch README to determine whether there are any specific prerequisites to be executed based on patch and patching methodologies.
Limitations
When running Rapid Platform Update, there are operational restrictions:
- OMS patching in parallel with two or more different patches: You should not apply any other patches on the OMS until the complete patching activity is done.
- Additional OMS deployment should not be performed during the deploy or pre-downtime activity phase. Doing so will place the system in an inconsistent state.
- Plug-in deployment or un-deployment: After the completion of the deploy phase (pre-downtime) activity, it is recommended not to perform any plug-in deployment/un-deployment until the update phase is complete.
OMSPatcher Command Updates
To support Rapid Platform Update operations, new command options have been added. In addition, updates to existing commands have been made.
The following table lists all OMSPatcher changes to support Rapid Platform Update patching.
| Command | Syntax | Additional Information |
|---|---|---|
|
|
|
Performs pre-downtime Metadata Registration Service (MRS) and SQL execution.
Recovery Operations If the pre-downtime operations have failed, do one of following while the OMS is up and running
|
|
|
|
The |
update |
omspatcher update |
This command will perform the downtime activity and complete the patching and bring up the OMS.
Recovery Method If there is downtime activity failure, do the following:
|
rollback deploy |
omspatcher rollback deploy |
If the failure occurs during the pre-downtime phase, this verb allows you to revert the system back to its original state prior to the failed patching attempt. If you do not want to complete the patching using update after the deploy is successful, then you can run this command to go back to the previous state. This is an online operation. |
status |
omspatcher status |
The command returns the status of the Oracle Home patching. Specifically, the following is shown:
|
resume |
omspatcher resume |
This command will resume the previous failed operation and is platform independent (instead of running previous resume.sh). |
Rapid Platform Update Patching Workflows
The following high-level workflows illustrate the patching process for Rapid Platform Update OMS patching.
Note:
For specifics on command option updates for Rapid Platform Update, see OMSPatcher Command Updates.Patch Deploy
Pre-downtime Activity
- Run OMSPatcher in Rapid Platform Update mode.
omspatcher deploy <p1 patch location>Running the
deploycommand in mode will execute pre-downtime tasks.
Patch Update
Downtime Activity
omspatcher update- Ensure you have backed up the middleware home (Recommended)
- Prompt for confirmation from administrators that the database has been backed up.
- Make sure you have available the procedure to take the DB backup.
Patch Rollback
- Shut down the OMS.
- Run the
rollbackcommand with the patches.omspatcher rollback -id <p1,p2,p3...> - Roll back the patches.
- Bring up the OMS.
Patching Use Cases
The following use cases demonstrate OMSPatcher command usage for various patching scenarios.
Prerequisites
- Download the patch that needs to be applied. See My Oracle Support: Searching for Patches.
- Make sure that the installed version of OMSPatcher and OPatch matches the version specified in the Readme of the patch being applied. This has to be updated in the Oracle Home.
| Use Case | Single OMS | Multi-OMS |
|---|---|---|
| Apply patch A | |
Run on the Primary OMS For multi-OMS environments, once the patching is completed on the primary OMS, a job will be started to patch the additional OMS. |
| Apply only the one-off patch without the Enterprise Manager Release Update |
|
Run on the Primary OMS |
|
Apply patch A Rollback patch A |
|
Run on the Primary OMS Once patchA jobs have finished execution on the Additional OMS, do the following:
|
| Weblogic/stack patches |
|
|
| Weblogic/stack patches with Enterprise Manager Release Update |
Suggestion: Consume the Release Update in non-nZDT mode as one downtime is required for Weblogic/stack patches.
|
Suggestion: Consume the RU in non-Rapid Platform Update mode as one downtime is required for Weblogic/stack patches.
|
Applying MRS Artifacts
For Rapid Platform Update, most of the MRS artifacts are applied during the pre-downtime phase.
The following workflow illustrates where in the patching process MRS artifacts need to be applied. As mentioned earlier, there are two patching phases corresponding to the OMS state:
- Pre-downtime
- Downtime
The following table shows the tasks to be performed during each phase.
| Pre-downtime | Downtime |
|---|---|
|
|
Troubleshooting
This chapter describes common OMSPatcher problems that may occur during patching operations or the analyze phase.
This chapter covers the following:
OMSPatcher Troubleshooting
In order for OMSPatcher to fully automate the patching process, it accesses various tools/utilities to carry out different patching tasks in their respective phases. The primary tools/utilities outside of OMSPatcher are:
-
emctl stop oms -
emctl start oms
These tools/utilities are accessed during the patching process. Note that failure during invocation of these utilities can also happen and the errors & remedies for those commands are not handled in this document. They need to be followed up with Oracle Support for details. However, OMSPatcher will trap errors from these commands output, push it to appropriate logs and announce it to the administrator and finally to support.
Apart from the above external tools/utilities, OMSPatcher uses the following internal utilities to do binary patching operations. They have separated log files generated by OMSPatcher. The internal utilities are patch binary prerequisite checks and patch binary apply, rollback operations.
OMSPatcher Log Management
This section refers to the information through logs published by OMSPatcher as part of its patching operations. This knowledge is needed for the administrator to obtain the appropriate logs from right area to troubleshoot and inform Oracle Support for further analysis. The following annotated example shows OMSPatcher apply output that displays the various log files that are created when running OMSPatcher.
Sample OMSPatcher apply Output
$ORACLE_HOME/OMSPatcher/omspatcher apply -bitonly
OMSPatcher Automation Tool
Copyright (c) 2017, Oracle Corporation. All rights reserved.
OMSPatcher version : 13.9.5.10.0
OUI version : 13.9.4.0.0
Running from : $ORACLE_HOME
Log file location : $ORACLE_HOME/cfgtoollogs/omspatcher/opatch2023-02-15_11-50-27AM_1.log
OMSPatcher log file: $ORACLE_HOME/cfgtoollogs/omspatcher/1111112/omspatcher_2023-02-15_11-50-27AM_apply.log
WARNING: OMSPatcher has been invoked with bitonly option but the System patch provided has deployment metadata.
Invocation in bitonly mode will prevent OMSPatcher from deploying artifacts.
Do you want to proceed? [y|n]
y
User Responded with: Y
Prereq "checkComponents" for patch 1111140 passed.
Prereq "checkComponents" for patch 1111143 passed.
Running apply prerequisite checks for sub-patch(es) "1111140,1111143" and Oracle Home $ORACLE_HOME"...
Sub-patch(es) "1111140,1111143" are successfully analyzed for Oracle Home "$ORACLE_HOME"
To continue, OMSPatcher will do the following:
[Patch and deploy artifacts] :
Do you want to proceed? [y|n]
y
User Responded with: Y
Applying sub-patch(es) "1111140,1111143"
Please monitor log file: $ORACLE_HOME/cfgtoollogs/opatch/opatch2023-02-15_11-50-31AM_1.log
Complete Summary
================
All log file names referenced below can be accessed from the directory "$ORACLE_HOME/cfgtoollogs/omspatcher/2023-02-15_11-50-27AM_SystemPatch_1111112_1"
Patching summary:
-----------------
Binaries of the following sub-patch(es) have been applied successfully:
Featureset Sub-patches Log file
---------- ----------- --------
oracle.sysman.top.oms_13.5.0.0.0 1111140,1111143 1111140,1111143_opatch2023-02-15_11-50-31AM_1.log
--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1) OMSPatcher has been invoked with bitonly option but the System patch provided has deployment metadata.
Invocation in bitonly mode will prevent OMSPatcher from deploying artifacts.
--------------------------------------------------------------------------------
Log file location: $ORACLE_HOME/cfgtoollogs/omspatcher/1111112/omspatcher_2023-02-15_11-50-27AM_apply.log
OMSPatcher succeeded.Log output to a consolidated directory
As shown in the example above, there is a reference to pushing all logs to a consolidated log directory. The following line in the trace example shows this consolidation log directory.
...
All log file names referenced below can be accessed from the directory "$ORACLE_HOME/cfgtoollogs/omspatcher/2023-02-15_11-50-27AM_SystemPatch_1111112_1"
...This consolidated log directory contains the following files (here with reference to the example for rollback).
$ ls -l $ORACLE_HOME/cfgtoollogs/omspatcher/2023-02-15_11-50-27AM_SystemPatch_1111112_1
-rw-r--r-- 1 myadmin g900 39975 May 30 03:24 1111126,1111137,1111155_opatch2018-05-30_03-23-31AM_3.log
-rw-r--r-- 1 myadmin g900 13219 May 30 03:24 1111126,1111155,1111137_opatch2018-05-30_03-22-01AM_2.log
-rw-r--r-- 1 myadmin g900 120 May 30 03:22 AdminServerStatusPrerequisites_2018-05-30_03-22-01AM.log
-rw-r--r-- 1 myadmin g900 66 May 30 03:22 RepositoryStatusPrerequisites_2018-05-30_03-22-01AM.log
-rw-r--r-- 1 myadmin g900 71 May 30 03:22 Swlib_Prerequisite_2018-05-30_03-22-01AM.log
-rw-r--r-- 1 myadmin g900 456 May 30 03:24 emctl_register_VCPUUtilization_2018-05-30_03-24-28AM.log
-rw-r--r-- 1 myadmin g900 451 May 30 03:24 emctl_register_eventsaux_2018-05-30_03-24-20AM.log
-rw-r--r-- 1 myadmin g900 418 May 30 03:24 emctl_register_mpcui_2018-05-30_03-24-34AM.log
-rw-r--r-- 1 myadmin g900 418 May 30 03:24 emctl_register_mpcui_2018-05-30_03-24-40AM.log
-rw-r--r-- 1 myadmin g900 12574 May 30 03:24 opatch2018-05-30_03-21-43AM_1.log
-rw-r--r-- 1 myadmin g900 3938 May 30 03:24 temp_apply_automation.xml
-rw-r--r-- 1 myadmin g900 3149 May 30 03:24 temp_rollback_automation.xml
All individual log files of all invocation commands are finally copied to a consolidated place as highlighted above. Each command naming convention is self-explanatory and it indicates the actual operations being performed in automation. The omspatcher log file will refer the individual log files so that administrator can easily connect to individual files to refer to any failure.
Logs for Oracle Support
If the administrator wants to contact Oracle Support, the administrator must provide the following references to Support.
-
Administrator interface trace(s).
-
Consolidated log directory as zip
-
OPatch log file
-
OMSPatcher log file
-
Output of
omspatcher lspatchescommand on all OMS instance homes.
OMSPatcher: Cases Analysis, Error Codes, and Remedies/Suggestions
Refer to the following table for common OMSPatcher error codes.
Table 5-9 OMSPatcher Error Codes
| Error Code | Description | Remedy/Suggestion |
|---|---|---|
|
231 |
Wrong Oracle WebLogic Administration Server URL and/or invalid credentials |
Correct the interview inputs and run OMSPatcher again. |
|
234 |
Malformed Oracle WebLogic Administration Server URL |
If the Oracle WebLogic Administration Server URL is already defaulted (value given), type <enter>. If it is not given, construct the Oracle WebLogic Administration Server URL as t3s://<WebLogic Administration Server host address>:<WebLogic Administration Server port> .of the domain that controls the managed server on which the OMS is deployed. |
|
235 |
Unable to connect to OMS repository |
Check the OMS repository connectivity for SYSMAN administrator and run OMSPatcher again. |
|
236 |
OUI central inventory read issue |
Check if the OUI inventory is locked by some other processes. Check if OUI inventory is readable. |
|
238 |
Patch binary prerequisite checks failure |
Check OMSPatcher, OPatch, patch binary prerequisite log files for more details on the errors. If not resolved, contact Oracle Support. |
|
240 - 251 |
Binary updates (or) deployment failure |
|
|
233 |
Software library not configured OMS repository connectivity not achieved. (post successful check of the same during credential inputs Oracle WebLogic Administration Server not reachable (post successful check of the same during credential inputs) |
Check the OMSPatcher log file for the failure. |
OMSPatcher: External Utilities Error Codes
The following table lists exit codes for external utilities that OMSPatcher uses for life cycle and deployment. If the deployment (or) life cycle fails through OMSPatcher, the administrator can search individual log files for the error messages shown in the Error Message/Recommendation column.
Table 5-10 OMSPatcher External Utilities Error Codes
| Exit Code | Error Message / Recommendation |
|---|---|
|
34 |
Displays the usage of the command. |
|
35 |
Unable to read password! Exiting... |
|
36 |
Unable to get a connection to the repository! Exiting... |
|
37 |
The Plug-in is not deployed on this Management Server. The plug-in has to be deployed first to register metadata for that plug-in. |
|
38 |
Input file does not exist |
|
39 |
This operation is not supported by service. |
|
40 |
Metadata operation is skipped. |
|
41 |
Error occurred during Metadata registration. |
|
42 |
Error occurred during Metadata de-registration. |
Special Error Cases for OMSPatcher OMS Automation
This section provides issue resolution information for special cases when using OMSPatcher. This information will allow the administrator to handle these issues easily with less need for support team intervention.
Windows patching failure due to lock of files by Oracle WebLogic Administration Server
In Windows operating systems, it has been noticed that some of the Enterprise Manager related files (used for patching) are locked by running of Oracle WebLogic Administration Server. As OMSPatcher required Oracle WebLogic Administration Server to be RUNNING for the configuration detection, we need to perform the following steps to make sure that this conflict with respect to environment and patching is removed.
-
Go to ORACLE_HOME
-
Run OMSPatcher in non-analyze mode. For further instructions, refer to the patch README and Administrator guide.
Once the OMSPatcher is run in non-analyze mode, it will check if active files are locked by Oracle WebLogic administration server and will provide a prompt as shown below (in silent mode it will be auto-yes):
Running prerequisite checks to verify if any files or services are locked by admin server process... Please monitor OPatch log file: c:\MW_130518\oms\cfgtoollogs\opatch\1111112_Jun_ 26_2014_08_16_19\ApplyPrereq2014-06-26_08-16-57AM_8.log The details are: Following files are active : c:\MW_130518\oms\sysman\jlib\emCoreConsole.jar Due to active files to be patched, OMSPatcher will stop all OMS processes so tha t lock on active files may be released... Do you want to proceed? [y|n] y User Responded with: Y OMSPatcher has stopped all OMS processes successfully.
If there is a failure while stopping OMS processes, OMSPatcher will accordingly error out. Refer to the OMSPatcher log file for details.
-
OMSPatcher will stop the stack and then ask for a confirmation from the administrator on whether to proceed with prerequisite checks of patch binaries (in silent mode it will be auto-yes):
OMSPatcher has stopped all OMS processes successfully. Please make sure the above listed active files are unlocked by all windows processes. Do you want to proceed? [y|n] y User Responded with: Y
Note:
Administrators are requested to use some open source utilities like process explorer and search for file strings given as output in (2) to check if any files are still active. If so, kill the process tree of those files so that OPatch will run the checks, patch, and deploy the automation elements.
-
OMSPatcher will not attempt to re-start the stack. The administrator must restart the stack as needed.
A complete sample trace of this case is shown below:
C:\MW_130518\oms\OPatch_June26>omspatcher apply ..\patches\cmdRcu\1111112 OMSPatcher Automation Tool Copyright (c) 2016, Oracle Corporation. All rights reserved. OMSPatcher version : 13.8.0.0.0 OUI version : 13.8.0.0.0 Running from : c:\MW_130518\oms Log file location: c:\MW_130518\oms\cfgtoollogs\omspatcher\omspatcher2014-06-26_08-16-19AM_1.log omspatcher log file: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112\opatch_oms_2014-06-26_08-16-23AM_deploy.log Please enter the WebLogic Admin Server URL for primary OMS:> t3s://example.o racle.com:7101 Please enter the WebLogic Admin Server username for primary OMS:> weblogic Please enter the WebLogic Admin Server password for primary OMS:> Configuration Validation: Success Running prerequisite checks to verify if any files or services are locked by admin server process... Please monitor OPatch log file: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112_Jun_26_2014_08_16_19\ApplyPrereq2014-06-26_08-16-57AM_8.log The details are: Following files are active: c:\MW_130518\oms\sysman\jlib\emCoreConsole.jar Due to active files to be patched, omspatcher will stop all OMS processes so that lock on active files may be released... Do you want to proceed? [y|n] y User Responded with: Y omspatcher has stopped all OMS processes successfully. omspatcher has stopped all OMS processes successfully. Please make sure the above listed active files are unlocked by all windows processes. Do you want to proceed? [y|n] y User Responded with: Y Running apply prerequisite checks for patch(es) "1111112" and Oracle Home "c:\MW _130518\oms"... Please monitor omspatcher log file: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112_Jun_26_2014_09_01_33\ApplyPrereq2014-06-26_09-03-41AM_10.log Patches "1111112" are successfully analyzed for Oracle Home "c:\MW_130518\oms" To continue, OMSPatcher will do the following: [Patch and deploy patch(es) binaries] : Apply patch(es) [ 1111112 ] to Oracle Home "c:\MW_130518\oms"; Apply RCU artifact with patch "c:\MW_130518\oms\.omspatcher_storage \1111112_Feb_21_2014_06_30_38\original_patch" Do you want to proceed? [y|n] y User Responded with: Y Applying patch "1111112" to Oracle Home "c:\MW_130518\oms"... Please monitor OMSPatcher log file: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112_Jun_26_2014_09_01_33\apply2014-06-26_09-04-17AM_12.log Updating repository with RCU reference file "c:\MW_130518\oms\.omspatcher_storage\1111112_Feb_21_2014_06_30_38\original_patch" Copying all logs to: c:\MW_130518\oms\cfgtoollogs\omspatcher\2014-06-26_09-01-32AM_SystemPatch_1111112_1 Patching summary: Following patch(es) are successfully applied (Oracle home:patch list): c:\MW_130518\oms:1111112 Log file location: c:\MW_130518\oms\cfgtoollogs\omspatcher\1111112\omspatcher_oms_2013-06-26_09-01-36AM_deploy.log OMSPatcher succeeded.