1. User's Guide
  2. Out-of-Place Patching

7 Out-of-Place Patching

Out-of-place patching, which is based on cloning, is a patching method where patching is performed by creating a copy of oracle home, applying patches to the copied home, and then switching services to the copied home. This patching method helps in reducing the downtime of switching of the services from the existing home to the updated home.

Following are the important operations performed in out-of-place patching:

  1. Prepare clone home - A copy of the oracle home is created and patches are applied to the copied home.

  2. Switch to clone home - After the copied home is ready, the required services are switched to the copied home.

  3. Switch back to original home - When required, the services can be switched back to the original home.

OPatchauto supports out-of-place patching for the following configurations:

GI RAC

Following are the supported sub-configurations of Grid Infrastructure (GI) Real Application Cluster (RAC):

  • Non shared GI, non shared RAC

  • Shared GI, non shared RAC

  • Shared GI, shared RAC

  • Non shared GI, shared RAC

  • RAC one database

  • GI only

  • Single RAC home or multiple RAC homes

  • Software-only homes

Note:

  • This feature is supported from RDBMS version 12.2 and later.

  • For the software-only homes sub-configuration, only the prepare feature is supported. The switch to new home or rollback to original home is not supported.

Out of Place Patching Method

In the Out of Place Patching method a clone home is created and then the original home is switched to the clone home.

Note:

The Out of Place Patching Method (with explicit outofplace option) is applicable for DB 12.2 to DB 18.

To apply the patches, run the following command:

${ORACLE_HOME}/OPatch/opatchauto apply ${PATCH_HOME} -outofplace

or

${ORACLE_HOME}/OPatch/opatchauto apply ${PATCH_HOME} -outofplace –oh oh1, oh2

Where, PATCH_HOME is the location of the patch directory that contains the patch.

The apply session is an active session for all the homes, which are involved in patching, until the session is not completed on all the nodes.

At this stage, OPatchauto generates a default path for the cloned home on the first node and requests you for a confirmation through the interactive mode. You can continue with the default path or choose a custom path for each of the home that needs to be patched.

If you choose a custom path, then ensure that the provided directory path has the required write-permission and is not an existing directory across all the nodes. The custom path is validated by OPatchauto for all the nodes for existence. For all the nodes, OPatchauto finalizes the custom path for the entire OPatchauto OOP session and you would not be prompted again for confirming the path for the subsequent nodes. Once the paths are finalized, if the same path is found in a node (after the first node) then the OOP operation fails and you must delete the directory for the OOP operation to proceed.

You can also use the silent mode, where the interactive option is not displayed. You need to provide a property file containing a map of the original homes to cloned homes. The custom path is validated by OPatchauto for all the nodes for existence. If the path already exists on any node or a path is missing for any of the nodes, then the session fails and you must provide a new path which can be created on all the nodes.

To create a property file, add all the required original and cloned home details and save the file with the .properties extension. For example: clone.properties.

Following is an example of the property file: 

/scratch/product/12.2/<orginal_home>=/scratch/product/12.2/<cloned_home>
/scratch/product/db/12.2/<orginal_home>=/scratch/product/db/12.2/<cloned_home>

Where,

<original_home> is the folder name of the original home.

<cloned_home> is the folder name of the clone home to which the original home would be cloned to.

Following are other applicable command-line options:

[ -phBaseDir <patch.base.directory> ]
[ -log <log> ]
[ -logLevel <log_priority> ]
[ -analyze ]
[ -invPtrLoc <inventory.pointer.location> ]
[ -force_conflict ]
[ -database <database> ]
[ -nonrolling ]
[ -silent <map.original.to.clone>]

Note:

The database switching and SQL operation will be performed only on the last node.

Switchback to original home

To rollback the applied patches, you need to switch back to original home.

To switch back to the original home, run OPatchauto from the cloned home. OPatchauto switches back all the cloned homes to original homes, which were switched earlier when applying the patch.

To switch back to original home, run the following command:

${ORACLE_HOME}/OPatch/opatchauto rollback -switch-clone

or

${ORACLE_HOME}/OPatch/opatchauto rollback -switch-clone –oh oh1, oh2

Note:

  • OOP works only with the new home and the last home.

  • If you want to switchback to a previous oracle home instance, an instance before applying any of the previous patches, then use the inplace patching option.

  • Do not modify anything in the original home before switchback. After creating the clone home, if there are any changes made to the original home, then OPatchauto switchback would not be allowed.

  • The database switching and SQL operation will be performed only on the last node.

SIHA SIDB

The SIHA SIDB configuration and procedures are similar to the GI RAC configuration. For information about how apply patches, see GI RAC.

-nonrolling option is not applicable to the SIHA SIDB configuration.