How to Patch Oracle Grid Infrastructure 19c Using Out-Of-Place OPatchAuto

Grid Infrastructure 6 Minutes

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

Other Blog Posts in This Series

Published

20 thoughts on “How to Patch Oracle Grid Infrastructure 19c Using Out-Of-Place OPatchAuto”

  1. Please tell me you will do a similar blog for Oracle restart (i.e single node)
    The reason I ask is that many of the MOS support notes exclude Oracle Restart from the procedure.

    Like

    Reply

  3. Hi,

    Thank you for the work you do with these posts. I find them very usefull.

    Regarding this post here, I have a question. You stress the point, that one must not modify the cloned/patched ORACLE_HOME prior to doing the switch to the new version.

    But… How do we handle OneOff patches that need to be applied? Either those recommended in MOS ID 555.1 or OneOffs for bugs we have encountered (and therefore need) but which haven’t been included in the RUs, yet.

    Like

    Reply

  4. Hey Daniel,

    Great blog post! I’m so used to re-installing and patching a new home that I hadn’t used the OPatch clone feature. Thanks for sharing that—so much easier!

    I think I found a typo under step 3, “Switch to the New GI Home” the opatchauto apply command example lists the patch directory and the -switch-home option, but they’re mutually exclusive. Using both gives this error:
    OPATCHAUTO-68158: The arguments specified are mutually exclusive.
    OPATCHAUTO-68158: The “-switch-clone” argument is mutually exclusive with following argument : [patch-location]
    OPATCHAUTO-68158: Provide only one of the arguments.

    I think it should read:

    $ORACLE_HOME/OPatch/opatchauto apply -switch-clone

    Cheers,
    Sean

    Like

    Reply

  5. Hi Daniel,

    neither Doc ID 2419319.1 nor Doc ID 2853839.1 does apply to SIHA/Oracle Restart. So please take the time to cover SIHA/Restart here.

    Thx.
    Robert

    Like

    Reply

  7. @Dmitry

    Thank you for sharing. I figured it out meanwhile together with support and found the very same procedure. So it works exactly this way.

    Liked by 1 person

    Reply

  8. Hi Danial,

    We are very much looking for the procedure to do OutOfPlace Patching using opatchauto for GI + DB for SIHA/Oracle Restart.

    Could you please update if possible ?

    Thanks in advance

    Mvh,
    Chirag

    Like

    Reply

    1. Hi Chirag,
      Thanks for your interest. It’s for sure on my to-do list, but …. my list keeps on growing! :)
      When I do a post, I won’t use opatchauto, I’m sure, but the alternate method where you manually switch to the new home. This sounds like a better approach to me.
      Stay tuned – hopefully I find time soon.
      Regards,
      Daniel

      Like

      Reply

  9. Hi Daniel!

    I saw your presentation on Out of Place Patching at the DOAG conference and am now trying it out. Thank you very much for all the helpful tips!

    In your opinion, which method should be preferred; the one mentioned here with opatchauto or the new installation via gridSetup and SwitchGridHome (https://dohdatabase.com/2023/02/15/how-to-patch-oracle-grid-infrastructure-19c-using-out-of-place-method/)?

    What significant differences do you think exists?

    Regards
    Kay.

    Like

    Reply

    1. Hi Kay,

      Thanks for coming to my presentation. I’m glad that you listened to my advice and are exploring out-of-place patching.

      My absolute favorite is the SwitchGridHome method. It gives you much more control and transparency. It allows you to use golden images and you can deploy the Oracle homes in advance.

      Please – start using SwitchGridHome. Don’t start with opatchauto :)

      Regards,
      Daniel

      Like

      Reply

  10. When I try to use the phBaseDir with the prepare-clone command, it errors out with unable to create the patch bundle. Is there a way to apply the RU, OJVM and DP patchsets as part of the prepare-clone. Works fine with jus the RU. Is there a way to apply the OJVM and DP after the prepare-clone but before the switch-home?

    Like

    Reply

    1. Hi Cliff,
      I would believe that it should work. However, I don’t have much experience with OOP using OPatchAuto. If you run into problems, you should create an SR. I don’t know the answer because I rarely use it.
      I would encourage you to patch using SwitchGridHome instead. There, you can easily do it, and it is my absolute favorite:

      How to Patch Oracle Grid Infrastructure 19c Using Out-Of-Place SwitchGridHome

      Regards,
      Daniel

      Like

      Reply

  11. Hi Daniel , Thanks for Post , Currently we are performing patching for SIHA in our LAB environment , from above 2 step method , we have done the patch for grid , which is successful and for database does we need to do same step ? Also , during the prepare clone for GRID or DB, do we need to close the any database or any other services ?

    Like

    Reply

    1. Hi,

      I have little experience with OPatchAuto and the two-step process.

      I prefer the SwitchGridHome method since it offers much better flexibility. If you are looking to update your procedures, I really think you should consider SwitchGridHome instead of OPatchAuto.

      OPatchAuto can handle the database and GI at the same time, or separately, that’s up to you to decide.

      In the prepare phase there’s no interuption to the database.

      Regards,
      Daniel

      Like

      Reply

Leave a reply to Daniel Overby Hansen Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.