8 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:

8.1 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:

  • OPatchauto recommends completion of a single operation, like prepare or switch, on all the nodes before proceeding with the next operation.

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

You can apply patches by using any of the following methods:

8.1.1 Two-step method

To apply patches by using the two-step method, complete the following steps:

  1. Prepare a clone home by running the following command:

    ${ORACLE_HOME}/OPatch/opatchauto apply ${PATCH_HOME} -prepare-clone

    or

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

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

    After the prepare session starts, it has to be completed on all the nodes before running the switch operation. The prepare session is an active session for all the homes, which are involved in patching, until the prepare 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.

    Note:

    Do not modify anything in the created cloned home. After creating the clone home, if there is any changes made to the cloned home, then OPatchauto switch would not be allowed.

    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> ]
    [ -remote ]
    [-silent <map.original.to.clone>]
    

    Points to remember:

    • The -nonrolling option is not supported for out-of-place patching.

    • For shared homes, the -nonrolling option is not required.

  2. Prerequisite: Prepare clone home must be completed on all the nodes.

    Switch to clone home by running the following command:

    ${ORACLE_HOME}/OPatch/opatchauto apply ${PATCH_HOME} -switch-clone

    or

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

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

    The switch operation is performed only on oracle homes, which is created by OPatchauto. You can run the prepare operation multiple times to create more cloned homes. However, the switch operation is performed on the last prepared clone home.

    The switch operation is supported for the provided set of homes, which were requested together for a single prepare session on all the nodes.

    Note:

    Do not remove the original home from where the switch operations were performed. If you remove the original home, then the rollback action is not possible.

    The original home should be removed only when you are sure about using the cloned home with its patches and do not plan to roll back to the original home.

    Following are other applicable command-line options:

    [ -phBaseDir <patch.base.directory> ]
      [ -log <log> ]
    [ -logLevel <log_priority> ]
    [ -analyze ]
    [ -invPtrLoc <inventory.pointer.location> ]
    [ -wallet <wallet> ]
    [ -force_conflict ]
    [ -database <database> ]
    [ -remote ]
    [ -nonrolling]
    

8.1.2 Single-session method

In the single-session method a clone home is created and then the original home is switched to the clone home.

To apply the patches, run the following command:

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

or

${ORACLE_HOME}/OPatch/opatchauto apply ${PATCH_HOME} -outpfplace –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> ]
[ -remote ]
[ -nonrolling ]
[ -silent <map.original.to.clone>]

8.1.3 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 same home where OPatchauto was run to switch to a clone 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 ${PATCH_HOME} -switch-clone –oh oh1, oh2

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

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 apply any of the previous patches, then use the inplace patching option.

8.2 SIHA SIDB

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

The following options are not applicable to the SIHA SIDB configuration:

  • -nonrolling

  • -remote