Let me show you how I patch Oracle Grid Infrastructure 19c (GI) using the out-of-place method and opatchauto.

My demo system:

• Is a 2-node RAC
• Runs Oracle Linux
• Is currently on 19.16.0, and I want to patch to 19.17.0

When I use this procedure, I patch both the GI home only. I can patch the database later.

Preparation

I need to download:

1. Latest OPatch from My Oracle Support (6880880).
2. The 19.17.0 Release Update for Oracle Grid Infrastructure from My Oracle Support. I use patch 34416665.

You can use AutoUpgrade to easily download GI patches.

I place the software in /u01/software.

How to Patch Oracle Grid Infrastructure 19c

1. Make Ready for Patching

I can do this in advance. It doesn’t cause any downtime.

1. I ensure that there is passwordless SSH access between all the cluster nodes:

   [grid@copenhagen1]$ ssh copenhagen2 date
   
   [grid@copenhagen2]$ ssh copenhagen1 date
   

2. I update OPatch to the latest available version.

   • On all nodes (copenhagen1 and copenhagen 2)
   • In the GI home as grid

   I just show how to do it for the GI home on one node:

   [grid@copenhagen1]$ cd $ORACLE_HOME
   [grid@copenhagen1]$ rm -rf OPatch
   [grid@copenhagen1]$ unzip -oq /u01/software/p6880880_190000_Linux-x86-64.zip
   

3. I extract the patch file on both nodes. I show it for just the first node:

    [grid@copenhagen1]$ cd /u01/software
    [grid@copenhagen1]$ mkdir 34416665
    [grid@copenhagen1]$ mv p34416665_190000_Linux-x86-64.zip 34449117
    [grid@copenhagen1]$ cd 34416665
    [grid@copenhagen1]$ unzip p34416665_190000_Linux-x86-64.zip
   

4. I check for patch conflicts.

   • I can find the details about which checks to make in the patch readme file.
   • I must check for conflicts in the GI home only.
   • Since I have the same patches on all nodes, I can check for conflicts on just one of the nodes.

   As grid with ORACLE_HOME set to the GI home:

   [grid@copenhagen1]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/34416665/34416665/34419443 | grep checkConflictAgainstOHWithDetail
   [grid@copenhagen1]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/34416665/34416665/34444834 | grep checkConflictAgainstOHWithDetail
   [grid@copenhagen1]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/34416665/34416665/34428761 | grep checkConflictAgainstOHWithDetail
   [grid@copenhagen1]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/34416665/34416665/34580338 | grep checkConflictAgainstOHWithDetail
   [grid@copenhagen1]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/software/34416665/34416665/33575402 | grep checkConflictAgainstOHWithDetail
   

2. Clone Home and Patch

Like phase 1, I can do this in advance. No downtime.

1. First, on copenhagen1, I clone the existing GI home. I set ORACLE_HOME to my existing GI home. As root:

   [root@copenhagen1]$ export ORACLE_HOME=/u01/app/19.0.0.0/grid
   [root@copenhagen1]$ export PATH=$ORACLE_HOME/OPatch:$PATH
   [root@copenhagen1]$ $ORACLE_HOME/OPatch/opatchauto \
      apply /u01/software/34416665/34416665 \
      -prepare-clone \
      -oh $ORACLE_HOME
   

   • opatchauto prompts me for the location of the new GI home. I choose the following location:
     • /u01/app/19.17.0/grid
   • Optionally, I can specify the new location in a response file. See appendix.
   • opatchauto clones the GI home and applies the patches.
2. Next, I clone on the other node. On copenhagen2, I repeat step 1.
   • opatchauto automatically chooses the same locations for GI home as I used on the first node.

Do not touch the new, cloned homes. The next step will fail if you make any changes (like applying additional patches).

3. Switch to the New GI Home

Now, I can complete the patching process by switching to the new GI home. I do this one node at a time.

1. First, on copenhagen1, I switch to the new GI home. ORACLE_HOME is still set to my existing GI home. As root:

   [root@copenhagen1]$ export ORACLE_HOME=/u01/app/19.0.0.0/grid
   [root@copenhagen1]$ export PATH=$ORACLE_HOME/OPatch:$PATH
   [root@copenhagen1]$ $ORACLE_HOME/OPatch/opatchauto apply -switch-clone
   

   • Be sure to start with the same node you did when you cloned the GI home (phase 2).
   • This step stops the entire GI stack, including the resources it manages (databases, listener, etc.). This means downtime on this node only. The remaining nodes stay up.
   • In that period, GI marks the services as OFFLINE so users can connect to other nodes.
   • If my database listener runs out of the GI home, opatchauto will move it to the new GI home, including copying listener.ora.
   • Optionally, if I want a more graceful approach, I can manually stop the services and perform draining.
   • In the end, GI restarts using the new, patched GI home. GI restarts the resources (databases and the like) as well.
   • Proceed with the rest of the nodes as quickly as possible.
2. I connect to the other node, copenhagen2, and repeat step 1.
   • If I had more nodes in my cluster, I must process the nodes in the same order as I did the cloning (phase 2).
3. I update any profiles (e.g., .bashrc) and other scripts referring to the GI home on all nodes.

That’s it! I have now patched my Grid Infrastructure deployment.

In my demo environment, each node was down for around 7 minutes. But the database remained up on other nodes all the time.

For simplicity, I have removed some of the prechecks. Please follow the patch readme file instructions and perform all the described prechecks.

In this blog post, I decided to perform the out-of-place patching as a two-step process. This gives me more control. I can also do it all in just one operation. Please see Grid Infrastructure Out of Place ( OOP ) Patching using opatchauto (Doc ID 2419319.1) for details.

Later on, I patch my database.

A Word about the Directory for the New GI Home

Be careful when choosing a location for the new GI home. The documentation lists some requirements you should be aware of.

In my demo environment, the existing GI home is:

/u01/app/19.0.0.0/grid

Since I am patching to 19.17.0, I think it makes sense to use:

/u01/app/19.17.0/grid

If your organization has a different naming standard, that’s fine. Just ensure you comply with the requirements specified in the documentation.

Don’t Forget to Clean Your Room

At a future point, I need to remove the old GI home. I use the deinstall tool in the Oracle home.

I execute the command on all nodes in my cluster:

$ export OLD_GRID_HOME=/u01/app/19.0.0.0/grid
$ export ORACLE_HOME=OLD_GRID_HOME
$ $ORACLE_HOME/deinstall/deinstall -local

But I wait a week or two before doing so. To ensure that everything runs smoothly on the new patch level.

Happy Patching!

Appendix

Installing Multiple Patches

In the example above, I am just installing one patch. Often, you need to install multiple patches, like Release Update, Monthly Recommend Patches (MRP), and perhaps also one-offs.

OPatchAuto can install multiple patches in one operation. You can use -phBaseDir to specify a directory where you place all the patches as subdirectories:

opatchauto apply -phBaseDir <directory> ...

How to Use Prepare-Clone in Silent Mode

When I execute opatchauto apply -prepare-clone, the program prompts for the location of the new GI home. For an unattended execution, I can specify the old and new GI home in a file, and reference that file using the -silent parameter.

[root@copenhagen1]$ cat prepare-clone.properties
/u01/app/19.0.0.0/grid=/u01/app/19.17.0/grid

[root@copenhagen1]$ $ORACLE_HOME/OPatch/opatchauto apply ... -prepare-clone -silent prepare-clone.properties -oh $ORACLE_HOME

Further Reading

• MOS note: Grid Infrastructure Out of Place ( OOP ) Patching using opatchauto (Doc ID 2419319.1)
• Documentation: OPatch User’s Guide, Out-of-Place Patching

Other Blog Posts in This Series

• Introduction
• How to Patch Oracle Grid Infrastructure 19c Using In-Place OPatchAuto
• How to Patch Oracle Grid Infrastructure 19c Using Out-Of-Place OPatchAuto
• How to Patch Oracle Grid Infrastructure 19c Using Out-Of-Place SwitchGridHome
• How to Patch Oracle RAC Database 19c Using Manual Out-Of-Place
• How to Patch Oracle Grid Infrastructure 19c and Oracle Data Guard Using Standby-First
• How to Patch Oracle Grid Infrastructure 19c Using Zero Downtime Oracle Grid Infrastructure Patching
• How to Patch Oracle Restart 19c and Oracle Database Using Out-Of-Place Switch Home
• How to Patch Oracle Restart 19c and Oracle Data Guard Using Out-Of-Place Switch Home
• Which Method Should I Choose When Patching Oracle Grid Infrastructure 19c
• How to Avoid Interruptions When You Patch Oracle Grid Infrastructure 19c
• Patching Oracle Grid Infrastructure And Oracle Data Guard
• How to Clone Oracle Grid Infrastructure Home Using Golden Images
• How to Roll Back Oracle Grid Infrastructure 19c Using SwitchGridHome
• How to Remove an Old Oracle Grid Infrastructure 19c Home
• Use Cluster Verification Utility (cluvfy) and Avoid Surprises
• A Word about Zero Downtime Oracle Grid Infrastructure Patching
• Why You Need to Use Oracle Fleet Patching and Provisioning
• My Best Advice on Patching Oracle Grid Infrastructure
• Pro Tips