Limited Rolling Upgrade with OPATCH

Prior to Oracle 9i Release 2, whenever you were required to apply a patch to your RAC environment, you had to shut down all instances on each node under the specific ORACLE_HOME to be patched. As you can imagine, this did not sit well with programs that have high availability requirements. Starting with 9.2.0.2, and further enhanced in Oracle 10g, the server now supports the application of patches to nodes of a RAC cluster in a rolling manner with zero down time. Eligible patches can be applied using the opatch utility one node at a time, while the other active nodes in the cluster remain up and operational. Currently, only individual patchesthat is, one-off patches, not complete patch setsmay be classified by Oracle support as rolling upgradeable. Usually, patches that have the highest probability of becoming rolling upgradeable have the following characteristics:

• They are unrelated to the RAC internode communication infrastructure.

• They have no effect on database contents.

• They do not modify shared database components such as file headers, kernel modules, and control files.

Is Your One-Off Patch Rolling Upgradable?

Starting with 9.2.0.4, all one-off patches released by Oracle support will be classified as either rolling or not rolling. One-off patches prior to 9.2.0.4 were originally classified as not rolling, but could become eligible for re-release as rolling upon analysis from Oracle support. If you would like to see whether a specific one-off patch could become eligible for re-release as rolling upgradeable, contact Oracle support to reopen the bug. If approved, the current patch will become obsolete and a new patch will be released as rolling upgradeable.

You can check to see whether a patch has been marked rolling upgradeable by running $opatch query is_rolling or by checking the online_rac_installable flag for a value of trUE within etc/config/inventory directory. Usually, the patch README file should detail whether the patch is rolling upgradeable, but when in doubt, you can use one of the aforementioned methods.

Also, rolling patch upgrades are not supported if your Oracle Home exists on a shared cluster file system. Rolling patch upgrades are only supported on clusters where each node has its own local copy of the Oracle binaries.

It is still possible to maintain high-availability requirements in your RAC environment in case your patch is not rolling upgradeable. For patches that do not qualify for this new feature, you can configure your RAC environment with 10g SQL Apply support via logical standby database. Before and after you complete the patch process, you can perform a scheduled switchover to ensure your user community does not experience any extended downtime. For more information about configuring 10g SQL Apply support for your RAC environment, please review the section titled "Applying Patch sets with Data Guard in Place" in Chapter 16, "Utilizing 10g Physical and Logical Standby with Data Guard."