Skip Headers
Oracle® Enterprise Manager Cloud Control Administrator's Guide
12c Release 3 (12.1.0.3)

E24473-27
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

16 Patching Oracle Management Service and the Repository

Important:

The patching methodology discussed in this chapter can only be used with Enterprise Manager Cloud Control Release 12.1.0.3 and later.

OPatchauto (introduced with version 11.1 of the OPatch utility) automates the patching process by generating custom patching instructions based your particular environment and then automatically applies the patch.

This chapter covers the following topics:

16.1 OPatch Automation

With OPatchauto, you can automatically patch a typical OMS configuration (core, plug-in homes) with minimal intervention.

OPatchauto performs many of the pre-patch checks such as:

  • Configuration-based prerequisite checks

  • Patch-based binary prerequisite checks

OPatchauto 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, OPatchauto is able to simplify patching tasks by automating most of the steps.

16.1.1 Supported OMS Configurations and OPatchauto Patchability

  • Single OMS – OMS application that runs from a single OMS instance of the system. OPatchauto performs patching and deployment operations

  • Multiple OMS – OMS applications that run on two or more machines. The OMSs 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. OPatchauto 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, administrator needs to follow the steps given by OPatchAuto.

  • Standby OMS – A HA (high availability) OMS configuration of Enterprise Manager which permits servicing requests when the primary OMS is down. When configured in this way, the standby OMS is managed by a different domain (managed by Oracle WebLogic Administration Server). OPatchauto only provides context-sensitive steps (text and HTML) that the administrator will need to carry out manually.

  • 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 OPatchauto.

  • Remote 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 16-1 Simple Multi-OMS System

OMS architecture

For a single OMS system (primary), OPatchauto will execute the patching steps. For a multi-OMS UNIX system, OPatchauto generates bash scripts for execution, one per OMS instance; follow the instructions given by OPatchauto to find those scripts. (Requires OPatch 11.1.10.0.2 or later) For Windows multi-OMS systems, OPatchauto will generate customized patching instructions/commands for the environment in text and HTML formats; administrators must execute these instructions to patch the various OMSs.

16.1.2 OUI Inventory Configurations

Apart from the target (or) instance-based configurations, OPatchauto utilizes installation configuration relationships established in the Oracle Universal Installer (OUI) inventory as core and plug-in Oracle Homes. A typical OMS 12c home from the OUI inventory is organized as follows:

   <Middleware Home>
    |_____platform home         
    |_____plugin homes
         |_____oracle.sysman.db.oms.plugin_12.1.0.0.0
         |_____oracle.sysman.emas.oms.plugin_12.1.0.0.0
         |_____oracle.sysman.mos.oms.plugin_12.1.0.0.0
               .
               .
               .

16.1.3 Supported Patch Format

Beginning with Enterprise Manager 12.1.0.3, 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
                |_____ etc/config/actions.xml
                |_____ files/Subpatch1 &rsquor;payload'
       Sub-patch2
                |_____  etc/config/inventory.xml
                |_____ etc/config/actions.xml
                |_____ files/Subpatch1 &rsquor;payload'

Notes:

  • For Enterprise Manager release 12.1.0.2 or below, OPatchauto is not supported for the released one-off patches. For these older releases, you must use OPatch and follow the patch README instructions.

  • OPatchauto and System patches are only supported by Enterprise Manager release 12.1.0.3 and above.

16.1.4 Supported Patching Methodologies

OPatchauto supports rolling mode only for System patches without any automation (binary-only patching through OPatchauto). For all other artifacts (MRS, SQL), OPatchAuto only supports complete system downtime patching operations.

Refer to the patch README for the explicit information on supported patching methodologies.

16.2 Required OPatchauto Parameters

OPatchauto 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

Because OPatchauto requires this input for each patching operation, OPatchauto provides the ability to encrypt the username and password via WebLogic encryption APIs and pass this information using a property file when running OPatchauto apply and rollback operations. The next section discusses how to create a property file.

16.2.1 Creating a Property File

The automated patching functionality achieved using opatchauto expects Oracle WebLogic Administration Server URL and credentials as an input for patching and configuration detection operations. Primarily, the Oracle 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. OPatch allows you to repeatedly provide the inputs using property file option.

Note:

The property file for a Primary OMS and Standby OMS are different, as they are in different domains.

To create a property file for OPatch:

Run the following script to create the Oracle WebLogic encrypted configuration and key files.

On UNIX:

$ OPatch/wlskeys/createkeys.sh –oh <full path of platform home> -location <location to put the encrypted files>

On Windows:

OPatch\wlskeys\createkeys.cmd –oh <full path of platform home> -location <location to put the encrypted files>

When prompted, enter the credentials of the Oracle WebLogic Administration Server that manages the Managed Server on which OMS instance is deployed. Two files are generated with the file names: config and key.

Create the property file with the following entries:

AdminServerURL=t3s://<host address from where admin server is running>:<port of the admin server>
AdminConfigFile=<'config' file location>
AdminKeyFile=<'key' file location>

16.3 Prerequisites for Running OPatchauto

Before running an OPatchauto 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 OPatch in the OMS platform home of each host. The latest OPatch is available from My Oracle Support, and release version 11.1.0.0.0. Patch 6880880

    If you do not have the latest OPatch version, follow the instructions outlined in the My Oracle Support note 224346.1 available at:

    https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=224346.1
    
  • Check your patch README to determine whether there are any specific prerequisites to be executed based on patch and patching methodologies.

Checking System Prerequisites

To make sure all prerequisite checks pass and no errors occur during the OPatchauto patching session, Oracle recommends running the following commands on each OMS instance (in your OMS system).

$<Platform Home>/OPatch/opatchauto apply –analyze 

Must be run from the System patch location (for apply operations)

Note:

Check the Patch README and the instructions given for chosen patching methodologies.

OR

$<Platform Home>/OPatch/opatchauto rollback –analyze –id  <list of sub-patches to be rolled back for System patch>  

Example 16-1 opatchauto apply -analyze Output

$opatchauto apply /omsSystemPatchV2/core_plugin_patches/1111123 -property_file /scratch/property_file -analyze
OPatch Automation Tool
Copyright (c) 2013, Oracle Corporation.  All rights reserved.
 
OPatchauto version : 11.1.0.10.2 
OUI version        : 11.1.0.11.0
Running from       : /multioms/middleware/oms
Log file location  : /multioms/middleware/oms/cfgtoollogs/opatch/opatch2013-06-09_08-20-25AM_1.log
 
opatchauto log file: /multioms/middleware/oms/cfgtoollogs/opatchauto/1111123/opatch_oms_2013-06-09_08-20-30AM_analyze.log
 
Configuration Validation: Success
 
Running apply prerequisite checks for patch(es) "1111111" and Oracle Home "/multioms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0"...
Please monitor OPatch log file: /multioms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0/cfgtoollogs/opatch/1111111_Jun_09_2013_08_20_25/ApplyPrereq2013-06-09_08-20-53AM_8.log
Patches "1111111" are successfully analyzed for Oracle Home "/multioms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0"
 
Running apply prerequisite checks for patch(es) "1111114" and Oracle Home "/multioms/middleware/oms"...
Please monitor OPatch log file: /multioms/middleware/oms/cfgtoollogs/opatch/1111114_Jun_09_2013_08_20_25/ApplyPrereq2013-06-09_08-20-55AM_8.log
Patches "1111114" are successfully analyzed for Oracle Home "/multioms/middleware/oms"
 
Copying all logs to: /multioms/middleware/oms/cfgtoollogs/opatch/2013-06-09_08-20-25AM_SystemPatch_1111123_1
 
Log file location: /multioms/middleware/oms/cfgtoollogs/opatchauto/1111123/opatch_oms_2013-06-09_08-20-30AM_analyze.log
 
opatchauto succeeded.

Example 16-2 opatchauto rollback -analyze output

36084 OPatch]$ ./opatchauto rollback -id 1111111,1111114 -property_file /scratch/property_file -analyze
OPatch Automation Tool
Copyright (c) 2013, Oracle Corporation.  All rights reserved.
 
OPatchauto version : 11.1.0.10.2
OUI version        : 11.1.0.11.0
Running from       : /singleoms/middleware/oms
Log file location  : /singleoms/middleware/oms/cfgtoollogs/opatch/opatch2013-06-09_08-26-02AM_1.log
 
opatchauto log file: /singleoms/middleware/oms/cfgtoollogs/opatchauto/SystemPatch/opatch_oms_2013-06-09_08-26-07AM_analyze.log

Configuration Validation: Success
 
Running rollback prerequisite checks for patch(es) "1111111" and Oracle Home "/singleoms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0"...
Please monitor OPatch log file: /singleoms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0/cfgtoollogs/opatch/1111111_Jun_09_2013_08_26_02/RollbackPrereq2013-06-09_08-26-16AM_8.log
Patches "1111111" are successfully analyzed for Oracle Home "/singleoms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0"
 
Running rollback prerequisite checks for patch(es) "1111114" and Oracle Home "/singleoms/middleware/oms"...
Please monitor OPatch log file: /singleoms/middleware/oms/cfgtoollogs/opatch/1111114_Jun_09_2013_08_26_02/RollbackPrereq2013-06-09_08-26-19AM_8.log
Patches "1111114" are successfully analyzed for Oracle Home "/singleoms/middleware/oms"
 
Copying all logs to: /singleoms/middleware/oms/cfgtoollogs/opatch/2013-06-09_08-26-02AM_SystemPatch_1111123_1
 
 
Log file location: /singleoms/middleware/oms/cfgtoollogs/opatchauto/SystemPatch/opatch_oms_2013-06-09_08-26-07AM_analyze.log
 
opatchauto succeeded.

Note

  • Once the analysis finishes, you can refer to the OPatchauto log to see what steps would be executed by OPatchauto in non –analyze mode. The log file contains references to the HTML and text output file HTML containing detailed steps.

  • If you are analyzing a standby OMS system, you must include the -standby option.

16.4 Using OPatchauto

OPatchauto must be run from the platform home of the OMS being patched. The ORACLE_HOME environment variable must be set as the platform home or provided using the OPatchauto "–oh" option. For example:

<Platform Home>/OPatch/opatchauto apply <patch>

Minimum Required OPatchauto Version: 11.1.0.10.2

Ensuring You Have the Latest Version of OPatch

OPatchauto uses the OPatch utility to apply the patch. For this reason, you must ensure that you have the latest version of OPatch 11.1 on all OMS instance platform homes. If you not sure which version of OPatch resides on your system, run the following command:

<Platform Home>/OPatch/opatchauto version

To download the latest version of OPatch, follow the instructions outlined in the My Oracle Support note 224346.1 available at the following location:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=224346.1

Patching Quickstart

Using OPatchauto typically involves the following phases:

1. Determining Whether Your System Meets OPatchauto System Requirements

Run opatchauto apply -analyze

The apply -analyze command simulates an OPatchauto 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 OPatchauto" for additional information.

2. Determining What System Patches Currently Exist on Your System

Run opatchauto lspatches

See "lspatches" for more information.

3. Obtaining Patches from My Oracle Support (MOS)

OPatchauto requires that the required platform or plug-in System patches be obtained from My Oracle Support and downloaded to the OMS instance on which OPatchauto is to be run.

See "My Oracle Support: Searching for Patches" for more information.

4. Applying a Patch

Run $opatchauto apply <patch>

The apply command applies all patches within a specified System patch to the platform home from which OPatchauto is command is run.

See "Running opatchauto apply" for more information.

5. Deinstalling Individual Sub-patches of a System Patch

Run $opatchauto 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 opatchauto rollback command.

See "Running opatchauto rollback" for more information.

16.4.1 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. The following figure shows the MOS home page.

Figure 16-2 My Oracle Support Main Page

mos overview

Note:

You can find complete documentation about MOS at the following location:

http://docs.oracle.com/cd/E25290_01/index.htm

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 shown in the following figure.

Figure 16-3 MOS Patches and Updates

mos patch

Click on the tab to access the Patches and Updates page. From here, you can search for the patches based on the OMS patch area (core, plug-in, or combination). The following examples illustrate OMS patch searches for the various patch areas.

From the Search tab, click Product or Family (Advanced).

Figure 16-4 Searching by Product or Family

OMS patch search

Example: Searching for OMS Core Patches

To search for Enterprise Manager OMS core patches, enter the following search parameters:

  • Product: Enterprise Manager Base Platform

  • Release: Cloud Control (OMS) 12.1.0.3.0

  • Platform: Linux x86-64

Clicking Search displays the following results.

Figure 16-5 OMS Core Patch Search Results

oms core search results

By clicking on patch 16729224 you are taken to the patch page where you can view bugs resolved by this patch, related Knowledge Articles, or view a generic patch README.

Figure 16-6 OMS Core Patch Page

OMS core patch page

Click Download to save the patch .ZIP file to your local system.

Figure 16-7 Patch Download Dialog

Surrounding text describes Figure 16-7 .

Example: Searching for OMS Plug-in Patches

To search for Enterprise Manager OMS plug-in patches (Database plug-in is used for this example), enter the following search parameters:

  • Product: Enterprise Manager for Oracle Database

  • Release: DB Plug-in (OMS) 12.1.0.3.0

  • Platform: Linux x86-64

In the search results, click on patch 16399225.

Figure 16-8 OMS Plug-in Patch Search Results

Surrounding text describes Figure 16-8 .

On the patch page, in addition to downloading the patch and viewing the README, you can also view/access bugs resolved by this patch.

Figure 16-9 OMS Plug-in Patch Page

Surrounding text describes Figure 16-9 .

16.4.2 Running opatchauto 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 opatchauto 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 opatchauto apply will perform patching and deployment operations.

On your local OMS instance, run the following command from the top level System patch directory:

$<Platform home>/OPatch/opatchauto apply <patch>

Note:

Unlike opatchauto analyze, you should not run opatchauto apply on every OMS instance. OPatchauto will either execute all patching and deployment operations, or will generate environment-specific steps that include complete configuration aspects of the System.

For a multi-OMS UNIX system, OPatchauto generates bash scripts for execution, one per OMS instance; follow the instructions given by opatchauto to find those scripts. (Requires OPatch 11.1.0.10.2 or later.) For Windows multi-OMS systems, OPatchauto will generate customized patching instructions/commands for the environment in text and HTML formats; administrators must execute these instructions to patch the various OMSs.

16.4.3 Running opatchauto 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 opatchauto 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 opatchauto rollback will perform the deinstallation operations.

On your local OMS instance, run the following command from the top level System patch directory:

$<Platform home>/OPatch/opatchauto rollback -id <list of comma separated sub-patches of System patch>

Note:

  • Unlike opatchauto analyze, you should not execute the opatchauto rollback command on every OMS instance. OPatchauto 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, Opatchauto generates bash scripts for execution, one per OMS instance; follow the instructions given by opatchauto to find those scripts. (Requires OPatch 11.1.0.10.2 or later) For Windows multi-OMS systems, OPatchauto will generate customized patching instructions/commands for the environment in text and HTML formats; administrators must execute these instructions to patch the various OMSs.

16.4.4 Running opatchauto lspatches

After the patch is applied or rolled back, you can run the opatchauto lspatches command to generate a comprehensive Oracle home – patches map of the OMS instance homes and installed patches.

Example 16-3 Sample opatchauto lspatches Output

$ ./opatchauto lspatches
OPatch Automation Tool
Copyright (c) 2013, Oracle Corporation.  All rights reserved.
 
Oracle Home:/singleoms/middleware/oms
1111114
13983293
 
Oracle Home:/singleoms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0
1111111
  
The following groups of patch(es) are applied as System Patch bundle(s):
1111114,1111111
 
For more details on individual homes, execute '$ORACLE_HOME/OPatch/opatch lsinventory -details -oh <desired home>'

16.4.5 Running opatchauto version

To determine the version numbers of the various OPatchauto utilities (Opatch, OPlan, OsysModel) that reside on your system, you can run opatchauto version.

Example 16-4 opatchauto version Output

$ ./opatchauto version
OPatch Version: 11.1.0.10.2
OPlan Version: 12.1.0.1.3
OsysModel build: Mon Jun 03 19:41:02 PDT 2013
opatchauto succeeded.

16.4.6 Patching a Standby OMS System

If you have configured a standby OMS for High Availability, refer to Chapter 30, "Enterprise Manager Disaster Recovery" and Appendix D, "Standby OMSs using Standby WebLogic Domain" for information on how to patch Standby OMS systems.


OPatchauto Command Syntax

This section provides a comprehensive listing and description of all OPatchauto commands used to patch an OMS.

Important:

OPatchauto commands must be run from the OMS Platform home.

OPatchauto Commands

The OPatchauto commands are run from the OMS Platform home out of the standard OPatch directory. The Platform home must be set as $ORACLE_HOME. In the following generic example, an OPatchauto command is run from a Platform home

<Platform home>/OPatch/opatchauto apply <PATH_TO_PATCH_DIRECTORY>

where <PATH_TO_PATCH_DIRECTORY> is the full path to the System patch top level directory.

OPatchauto consists of four primary commands.

  • apply

  • rollback

  • version

  • lspatches

OPatchauto help

You can view online help for any command (except version) by specifying the -help option.

For example:

  • opatchauto –help

  • opatchauto apply –help

  • opatchauto rollback –help

  • opatchauto lspatches –help


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.

Important: OPatchauto 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.

Syntax

<Platform home>/OPatch/opatchauto apply
                 [-jre <Path to JRE>]
                 [-nonrolling]
                 [-invPtrLoc <Path to oraInst.loc>]
                 [-property_file <Path to property file>]
                 [-analyze]
                 [-silent]
                 [-oh <Platform home path>]
                 [-standby]

Command Options

Table 16-1 Apply

Option Description

jre

Instructs OPatchauto to use a Java environment other than the JRE in the platform home.

nonrolling

If patch is rolling patch as per the README, opatchauto can execute in nonrolling fashion, if this option is provided.

invPtrLoc

Overrides the default inventory pointer file to be used by OPatchauto with a administrator-specified oraInst.loc file.

property_file

The administrator defined property file for OPatchauto to use. The path to the property file should be absolute.

The keys for OPatchauto are:

'AdminConfigFile' - Encrypted file for Administration Server administrator of the OMS instance domain.

'AdminKeyFile' - Encrypted file for Administration Server password of the OMS instance domain.

'AdminServerURL' - Administration 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 an opatchauto/opatch understood key and each pair is separated by newline in the property file.

In order to create encrypted files for Oracle WebLogic Administration Server username & password, run the following script:

$ORACLE_HOME/OPatch/wlskeys/createkeys.sh

(.cmd for Windows)

to obtain the files and load them through a custom file using the property_file option.

analyze

This option performs prerequisite checks that includes both configuration and binary prerequisite checks. It simulates an apply operation (does not apply the patch). The command &rsquor;opatchauto apply' with this option must be run on each OMS instance to make sure all prerequisites pass for patching operations.

silent

This option refers to silent mode of invocation.

oh

The parameter passed through this option will override ORACLE_HOME environment variable. This parameter (if this option is used) must be the core platform home.

standby

This option should be used when patching a standby OMS infrastructure.



Rollback

Rollback 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 opatchauto lspatches command. See "Running opatchauto lspatches".

Important: OPatchauto must be run from the platform home. ORACLE_HOME environment variable must be set as platform home or provided via the –oh option.

Syntax

opatchauto rollback -id <sub patches ID of a System patch>
               [-id <list of comma separated sub-patches of System patch>]
               [-invPtrLoc <Path to oraInst.loc>]
               [-jre <LOC>] [-silent] [-nonrolling]
               [-property_file <path to property file>]
               [-analyze] [-oh <Platform home path>]
               [-standby ]

Options

Table 16-2 Rollback

Option Description

id

List of sub-patches of a System patch. For a complete list of sub-patches, see the System patch README.

jre

This jre option instructs OPatchauto to use the JRE (java) from the specified location instead of the default location under Oracle Home.

nonrolling

The nonrolling option instructs OPatchauto to run the patching session run in 'nonrolling' mode. Before the patching session can start, the following prerequisites must be met:

  • The stack on the local node must be running

  • All remote nodes must be down.

invPtrLoc

The invPtrLoc option is used to locate the Central Inventory Pointer File (oraInst.loc). Input for this option is the path to the oraInst.loc file.

property_file

The administrator defined property file for opatchauto to use. The path to the property file should be absolute.

The keys for 'opatchauto' are:

'AdminConfigFile' - Encrypted file for Administration Server administrator of OMS instance domain.

'AdminKeyFile' - Encrypted file for Administration Server password of OMS instance domain.

'AdminServerURL' - Administration 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 opatchauto/opatch understood key and each pair is separated by newline in the property file.

In order to create encrypted files for Oracle WebLogic Administration Server username & password, Use

$ORACLE_HOME/OPatch/wlskeys/createkeys.sh (.cmd for Windows) to get the files and load it thorough a custom file by 'property_file' option.

analyze

This option helps us to do dry-run prerequisite checks that includes both configuration and binary prerequisite checks. The command &rsquor;opatchauto rollback' with this option must be run on each OMS instance to make sure all prerequisites pass for patching operations.

silent

This option refers to silent mode of invocation.

oh

The parameter passed through this option will override ORACLE_HOME environment variable. This parameter (if this option is used) must be the core platform home.

standby

This option should be used when patching a standby OMS infrastructure.



lspatches

Display patches and their Oracle home relationships with reference to OMS instances homes.

Syntax

opatchauto lspatches   [ -invPtrLoc <Path to oraInst.loc> ]
                       [-jre <LOC> ]
                       [-oh <Platform Oracle home> ]

Options

Table 16-3 lspatches

Option Description

jre

This jre option instructs OPatchauto to use the JRE (java) from the specified location instead of the default location under Oracle Home.

invPtrLoc

The invPtrLoc option is used to locate the Central Inventory Pointer File (oraInst.loc). Input for this option is the path to the oraInst.loc file.

oh

The parameter passed through this option will override ORACLE_HOME environment variable. This parameter (if this option is used) must be the core platform home.



version

The version command shows the current version number of the OPatch utility, dependent OPlan version, and the osysmodel version.

Important: OPatchauto must be run from the platform home.

Syntax

<GI_HOME>/OPatch/opatchauto 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 16-4 version Command Options

Option Description

-invPtrLoc

The invPtrLoc option is used to locate the Central Inventory Pointer File (oraInst.loc). Input for this option is the path to the oraInst.loc file.

-jre

This jre option instructs OPatchauto to use the JRE (java) from the specified location instead of the default location under Oracle Home.

-oh

The oh option specifies the Oracle Home to work on. This takes precedence over the environment variable ORACLE_HOME.



Standby OMS Patching

There are two methods used to implement a standby OMS:

1. Standby OMS - Replicating OMS, Software library and Repository Components

If a standby site is set up through file system replication (Enterprise Manager 12.1.0.3 and later), there is no need to patch the standby site to keep it in sync with the primary site. When you apply patches to the primary OMS, the changes are automatically replicated at the standby site either manually or via automatic storage replication. For more details on this approach, see "Enterprise Manager Disaster Recovery".

Using the data and storage replication, the standby site does not need to be patched.

2. Standby OMS Configured in Parallel with the Primary OMS System

When patches are applied on the primary site OMS, they must also be applied on the standby site Management Services. Note that patches typically update the Oracle Homes (via the OPatch apply command) and may require scripts to be run against the Management Repository. On the standby site, it is sufficient to update the Oracle Homes (using OPatchauto) and skip the running of scripts on the Management Repository because database changes are automatically propagated to the standby site using Data Guard. For more information, see Appendix D, "Standby OMSs using Standby WebLogic Domain."

To patch the standby site, run opatchauto apply and opatchauto rollback with the standby option.


Troubleshooting

This chapter describes common OPatchauto problems that may occur during patching operations or the analyze phase.

This chapter covers the following:


OPatchauto Troubleshooting Architecture

In order for OPatchauto 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 OPatch and OPatchauto are:

  • emctl stop oms - Life cycle

  • emctl start oms - Life cycle

  • emctl applypatch, emctl rollbackpatch – Apply, rollback SQL changes in the OMS repository SYSMAN schema respectively

  • emctl register, emctl deregister – Register, de-register metadata services with the right XMLs for MRS artifacts as per patch metadata instructions respectively

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, OPatchauto 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, OPatchauto uses the following internal utilities to do binary patching operations. They have separated log files generated by OPatchauto. The internal utilities are patch binary prerequisite checks and patch binary apply, rollback operations.


OPatchauto Log Management Architecture

This section refers to the information through logs published by OPatchauto 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 opatchauto apply output that displays the various log files that are created when running OPatchauto.

Sample OPatchauto Apply Output

$./opatchauto apply /omsSystemPatchV2/core_plugin_patches/1111123 -property_file /scratch/property_file -analyze
 
OPatch Automation Tool
 
Copyright (c) 2013, Oracle Corporation.  All rights reserved.
 
OPatchauto version : 11.1.0.10.2
 
OUI version        : 11.1.0.11.0
 
Running from       : /multioms/middleware/oms
 
Log file location  : /multioms/middleware/oms/cfgtoollogs/opatch/opatch2013-06-09_08-20-25AM_1.log

Consolidated OPatch log file – This log file contains all details of core OPatch session call references.

opatchauto log file: /multioms/middleware/oms/cfgtoollogs/opatchauto/1111123/opatch_oms_2013-06-09_08-20-30AM_analyze.log

OPatchauto log file – This log file contains configuration information, traces of calls to individual commands, SDK calls and also mentions what step(s) passed, failed.

In case of failure of steps, it contains the failed step as command and remaining list of steps to be executed. This is useful to proceed so that administrator can resolve the failure, execute the remaining steps and then reach a good state in patching.

Configuration Validation: Success
 
Running apply prerequisite checks for patch(es) "1111111" and Oracle Home "/multioms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0"...
 
Please monitor OPatch log file: /multioms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0/cfgtoollogs/opatch/1111111_Jun_09_2013_08_20_25/ApplyPrereq2013-06-09_08-20-53AM_8.log

Binary prerequisite log file for a sub-patch &rsquor;1111111'

Patches "1111111" are successfully analyzed for Oracle Home "/multioms/middleware/plugins/oracle.sysman.emas.oms.plugin_12.1.0.4.0"
 
Running apply prerequisite checks for patch(es) "1111114" and Oracle Home "/multioms/middleware/oms"...
 
Please monitor OPatch log file: /multioms/middleware/oms/cfgtoollogs/opatch/1111114_Jun_09_2013_08_20_25/ApplyPrereq2013-06-09_08-20-55AM_8.log

Binary prerequisite log file for a sub-patch &rsquor;1111114'

Patches "1111114" are successfully analyzed for Oracle Home "/multioms/middleware/oms"
 
Copying all logs to: /multioms/middleware/oms/cfgtoollogs/opatch/2013-06-09_08-20-25AM_SystemPatch_1111123_1

All sub-logs, command logs go to this directory. This is useful to know what output each individual commands, execution threw on the screen. They are kept in separate logs (one for each command executed as part of automation). The naming of the individual logs are self-explanatory.

Log file location: /multioms/middleware/oms/cfgtoollogs/opatchauto/1111123/opatch_oms_2013-06-09_08-20-30AM_analyze.log

OPatchauto log file will be printed at the end.

opatchauto succeeded.

Log output to a consolidated directory

As shown in the example above, there is a reference to pushing of all logs to consolidated log directory. The following line in the trace example shows this consolidation log directory.

...
 
Copying all logs to: /singleoms/middleware/oms/cfgtoollogs/opatch/2013-06-09_08-41-33AM_SystemPatch_1111123_1

...

This consolidated log directory would contain the following files (here with reference to analyze example for apply).

$ ls -l /singleoms/middleware/oms/cfgtoollogs/opatch/2013-06-09_08-41-33AM_SystemPatch_1111123_1
 
total 80
 
-rw-r--r--  1 admin dba  7759 Jun  9 08:42 1111111_apply2013-06-09_08-42-23AM_11.log
 
-rw-r--r--  1 admin dba  5343 Jun  9 08:42 1111111_ApplyPrereq2013-06-09_08-41-41AM_8.log
 
-rw-r--r--  1 admin dba  8489 Jun  9 08:42 1111114_apply2013-06-09_08-42-20AM_10.log
 
-rw-r--r--  1 admin dba  5440 Jun  9 08:42 1111114_ApplyPrereq2013-06-09_08-41-43AM_8.log
 
-rw-r--r--  1 admin dba   120 Jun  9 08:41 AdminServerStatusPrerequisites_2013-06-09_08-41-40AM.log
 
-rw-r--r--  1 admin dba    136 Jun  9 08:42 emctl_register_logmgmt_2013-06-09_08-42-28AM.log
 
-rw-r--r--  1 admin dba 10740 Jun  9 08:42 opatch2013-06-09_08-41-33AM_1.log
 
-rw-r--r--  1 admin dba  8252 Jun  9 08:42 rcu_applypatch_original_patch_2013-06-09_08-42-25AM.log
 
-rw-r--r--  1 admin dba    66 Jun  9 08:41 RepositoryStatusPrerequisites_2013-06-09_08-41-40AM.log
 
-rw-r--r--  1 admin dba    71 Jun  9 08:41 Swlib_Prerequisite_2013-06-09_08-41-40AM.log
 
-rw-r--r--  1 admin dba  3221 Jun  9 08:42 temp_apply_automation.xml
 
-rw-r--r--  1 admin dba  3242 Jun  9 08:42 temp_rollback_automation.xml
 
$

All the individual log files of each 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 &rsquor;opatchauto' 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

  • OPatchauto log file

  • Output of &rsquor;opatchauto lspatches' command on all OMS instance homes.


OPatchauto: Cases Analysis, Error Codes, and Remedies/Suggestions

Refer to the following table for common OPatchauto error codes.

Table 16-5 OPatchauto Error Codes

Error Code Description Remedy/Suggestion

231

Wrong Oracle WebLogic Administration Server URL and/or invalid credentials

Correct the interview inputs and run OPatchauto 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 OPatchauto 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 OPatchauto, 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

  • This is a case for single OMS system. Patching steps are decided by OPatchauto but it failed to execute steps. OPatchauto will print the failed executed step and the remaining steps to be executed for completion of patching operations. Administrator need to contact Oracle support with logs, resolve why it failed and then must execute manually the failed step and steps referred by OPatchauto (in OPatchauto log file) to complete operations.

  • In case of multi OMS (or) stand by OMS patching operations, failure of individual commands that got executed through text/html output must be brought to support notice for further diagnosis. After the failure condition is resolved, administrator need to execute the failed steps and further steps mentioned in HTML (or) text output to complete the patching operations.

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 OPatchauto log file for the failure.



OPatchauto: External Utilities Error Codes

The following table lists exit codes for external utilities that OPatchauto uses for life cycle and deployment. If the deployment (or) life cycle fails through OPatchauto, the administrator can search individual log files for the error messages shown in the Error Message/Recommendation column.

Table 16-6 OPatchauto 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 OPatchauto OMS Automation

This section provides issue resolution information for special cases when using OPatchauto. This information will allow the administrator to handle these issues easily with less need for support team intervention.

Windows analyze 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 OPatchauto 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.

  1. As per the patch README & guide, Administrator would try to run opatchauto analyze to check if configuration and binary prerequisites succeeds for each of the OMS instances homes. If in Windows, the files are locked due to Oracle WebLogic administration server, we should get binary prerequisite checks failure.

    Apply binary prerequisite checks failed for patch(es) "1111112".
     
    Copying all logs to: C:\MW_130~1\oms\cfgtoollogs\opatch\2013-06-19_02-55-10AM_SystemPatch_1111112_1
     
    OPatch failed: Some of the prerequisite checks to apply or rollback the patch(es) have failed.
     
    

    Error occurred during the Run patch(es) binary prerequisite checks phase.

    Detail: Some of the prerequisite checks to apply or rollback the patch(es) have failed.
    
    Log file location: C:\MW_130~1\oms\cfgtoollogs\opatchauto\1111112\opatch_oms_201
     
    3-06-19_02-55-14AM_analyze.log
     
    Recommended actions: Please check opatchauto, opatch, patch(es) binary prerequisite log files for more details on the errors. If not resolved, please contact Oracle Support.
    
    opatchauto failed with error code = 238
    
  2. Once binary patch prerequisite failure occurs, Administrator is recommended to open the individual patch binary prerequisite checks log and check the failure. If there are active files locked, the individual prerequisite checkActiveFilesAndExecutables would have failed in the consolidated OPatch prerequisites report (inside the log) and it would also show the files that are currently active.

    , CheckActiveServicesForWindows=[ Prerequisite Status: NOT ATTEMPTED (serious failure), Prerequisite output:
     
    The details are:
     
    Executable "C:\MW_130~1\oms\bin\oradim.exe" was not found in the Oracle Home, so not checking for active services.]
    , CheckActiveFilesAndExecutables=[ Prerequisite Status: FAILED, Prerequisite output:
     
    The details are:        
     
      Following files are active :
     
      C:\MW_130~1\oms\sysman\jlib\emCoreConsole.jar]
    
  3. To ascertain if these active files are due to Oracle WebLogic Administration Server, we recommend the following steps:

    1. Go to ORACLE_HOME\bin and run &rsquor;emctl stop oms –all' to stop the complete stack for OMS. Note that ORACLE_HOME is already set as Platform home.

    2. 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.

    3. For each OMS instance home:

      1. Navigate to ORACLE_HOME\OPatch2. Execute the following command:

      opatchauto checkApplicable -ph <System patch location> -oh <Platform home> (for apply operations)
      

      OR

      run: opatchauto checkApplicable -id <list of sub-patch IDs of System patch> -oh <Platform home> (for rollback operations)
      

      Note:

      For a complete list of sub-patches of the System patch, refer to the Patch README.

      If this command passes for each OMS instance home, it is confirmed that active files are only due to the Oracle WebLogic Administration Server being in the running home. Go ahead and apply the System patch. However, if active files still persist, Contact Oracle Support.

  4. Go to ORACLE_HOME\bin and run emctl start oms –admin_only.

  5. Run OPatchauto in non-analyze mode. For further instructions, refer to the patch README and Administrator guide.

    Once the OpatchAuto is run in non-analyze mode, it will check if active files are again 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_2013_08_16_19\ApplyPrereq2013-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, opatchauto 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
    opatchauto has stopped all OMS processes successfully.
    

    If there is a failure while stopping OMS processes, OPatchauto will accordingly error out. Refer to opatchauto log file for details.

  6. Opatchauto 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):

    opatchauto 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 again requested to check the process explorer tree and make sure that active files mentioned earlier in prerequisite log are not listed there.

    Once confirmed, OPatch will run the checks, patch, and deploy the automation elements.

  7. Note that OPatchauto 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>opatchauto apply ..\patches\cmdRcu\1111112
OPatch Automation Tool
Copyright (c) 2013, Oracle Corporation.  All rights reserved.
 
 
OPatchauto version : 11.1.0.10.2
OUI version        : 11.1.0.11.0
Running from       : c:\MW_130518\oms
Log file location  : c:\MW_130518\oms\cfgtoollogs\opatch\opatch2013-06-26_08-16-
19AM_1.log
 
opatchauto log file: c:\MW_130518\oms\cfgtoollogs\opatchauto\1111112\opatch_oms_
2013-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 adm
in server process...
Please monitor OPatch log file: c:\MW_130518\oms\cfgtoollogs\opatch\1111112_Jun_
26_2013_08_16_19\ApplyPrereq2013-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, opatchauto 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
opatchauto has stopped all OMS processes successfully.
 
 
opatchauto 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 OPatch log file: c:\MW_130518\oms\cfgtoollogs\opatch\1111112_Jun_
26_2013_09_01_33\ApplyPrereq2013-06-26_09-03-41AM_10.log
Patches "1111112" are successfully analyzed for Oracle Home "c:\MW_130518\oms"
 
To continue, OPatch 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_1
30518\oms\.patch_storage\1111112_Feb_21_2013_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 OPatch log file: c:\MW_130518\oms\cfgtoollogs\opatch\1111112_Jun_
26_2013_09_01_33\apply2013-06-26_09-04-17AM_12.log
 
Updating repository with RCU reference file "c:\MW_130518\oms\.patch_storage\111
1112_Feb_21_2013_06_30_38\original_patch"
 
Copying all logs to: c:\MW_130518\oms\cfgtoollogs\opatch\2013-06-26_09-01-32AM_S
ystemPatch_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\opatchauto\1111112\opatch_oms_20
13-06-26_09-01-36AM_deploy.log
 
opatchauto succeeded.

Multi-OMS Execution for UNIX based Systems

This section deals with possible issues you may encounter when running bash scripts generated by OPatchauto in multi-OMS (UNIX-based systems) environment. The following OPatchauto-generated output illustrates various script-based issues.

Example 16-5 OPatchauto Output: Multi-OMS, UNIX-based Environment

[vganesan@slc04rjr OPatch]$ ./opatchauto apply /net/slc00bnh/scratch/fisong/omsSystemPatchV2/Probanal/9111111
OPatch Automation Tool
Copyright (c) 2013, Oracle Corporation.  All rights reserved.
 
OPatchauto version : 11.1.0.10.2
OUI version        : 11.1.0.11.0
Running from       : /scratch/vganesan/multioms/middleware/oms
Log file location  : /scratch/vganesan/multioms/middleware/oms/cfgtoollogs/opatch/opatch2013-10-18_21-56-05PM_1.log
 
opatchauto log file: /scratch/vganesan/multioms/middleware/oms/cfgtoollogs/opatchauto/9111111/opatch_oms_2013-10-18_21-56-09PM_deploy.log
 
Please enter OMS weblogic admin server URL(t3s://slc04rjr.us.oracle.com:7101):>
Please enter OMS weblogic admin server username:> weblogic
Please enter OMS weblogic admin server password:>
 
Configuration Validation: Success
 
WARNING: OPatchauto cannot automate patching steps in multi-OMS environment. 
 
Please perform the following steps to complete patching operations.
-------------------------------------------------------------------
Please do 'analyze' in-order as given below:
 
1. Please copy the script "/scratch/vganesan/multioms/middleware/oms/.patch_storage/oms/scripts_2013-10-18_21-56-31/run_script#1_on_host_adc2100679_us_oracle_com_as_user_vganesan.sh" to "adc2100679.us.oracle.com" and execute the script with -analyze option.
2. Please execute the script "/scratch/vganesan/multioms/middleware/oms/.patch_storage/oms/scripts_2013-10-18_21-56-31/run_script#2_on_host_slc04rjr_us_oracle_com_as_user_vganesan.sh" on local host with -analyze option.
 
If all prerequisites are successful with -analyze, Please do actual patching operations as:
 
1. Please execute the script "run_script#1_on_host_adc2100679_us_oracle_com_as_user_vganesan.sh" on host "adc2100679.us.oracle.com".
2. Please execute the script "/scratch/vganesan/multioms/middleware/oms/.patch_storage/oms/scripts_2013-10-18_21-56-31/run_script#2_on_host_slc04rjr_us_oracle_com_as_user_vganesan.sh" on local host.
 
OPatch Session completed with warnings.
Log file location: /scratch/vganesan/multioms/middleware/oms/cfgtoollogs/opatchauto/9111111/opatch_oms_2013-10-18_21-56-09PM_deploy.log
 
opatchauto completed with warnings.

Note 1:

Generation of bash scripts is only available for UNIX based systems & OPatch 11.1.0.10.2.

Note 2:

OPatchAuto completes with warnings with clear messages For example:

WARNING: OPatchauto cannot automate patching steps in multi-OMS environment.

This means that patching and deployment are not complete until the administrator performs the bash script execution instructions generated by OPatchatuo.

Troubleshooting Bash Script Execution

The following section covers the most common issues you may encounter while executing OPatchauto-generated bash scripts in multi-OMS (UNIX-based) environments.

No Windows Support

Microsoft Windows does not support bash script execution. So, this optimization (steps reduction) is not applicable for Windows OMS PS2 environments. The older context sensitive individual steps output through OPatchAuto remains in Windows.

Bash script program availability

The scripts assume that bash is located at /bin/bash. However, if this is not true, make sure the first line of the scripts are updated with the output of whereis bash.

Order of bash scripts execution

Bash scripts must be executed in the order specified in OPatchauto-generated output. For example, run_script#1… should be executed before run_script#2…..

In-between command failure in bash script

If there is a failure in between execution of commands in the bash script, the script stops running. The OMS administrator must triage the failure and comment out (inserting a hash "#" character at the beginning of a line) the already executed portions of the script and restart the bash script execution. Make sure you do not to comment out prompts and prompt-related code in the script.

Complete execution needed for all bash scripts

ALL bash script steps must be executed. No script and no step within any script can be omitted, even in the event of failures. Patching is correct and complete if and only if all steps of all bash scripts are executed correctly as per the order specification.

Patch location (if mounted)

The patch location input may exist on a mounted location. The bash scripts try to perform a secure copy (SCP) from the local OMS (where the OPatchauto Perl script was invoked). The SCP attempt could fail if the location is mounted. The bash script will ignore the SCP failure.

OMS repository SYSMAN password and prompts

The bash script prompts for OMS repository SYSMAN password only at the point where a command requires this information. The script does not prompt for the SYSMAN password at the beginning of the script. For this reason, pay special attention to prompts at all places of the script execution. Bash script execution is not a silent execution.

The bash script prompt will appear as follows:

Please provide credential for OMS repository SYSMAN user:

The password will not be displayed.

Patch Transfer/Download

The script will provide an option to download patch from local OMS to remote nodes (for the scripts that involve remote nodes). If the patch is on shared location (or) already downloaded to a specified location mentioned by the script, a user can choose to input n when prompted, and ignore this transfer.