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

Let me show you how I patch Oracle Grid Infrastructure 19c (GI) using the in-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. However, opatchauto has the option of patching the database home as well.

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.

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 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
    
  2. 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
    
  3. I check for patch conflicts.

    • In the patch readme file I can find the details about which checks to make.
    • 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. Start Patching

Now, I start the actual patch process. I do this one node at a time.

  1. First, as root on copenhagen1, I use opatchauto to patch my GI home:

    [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/app/grid/patches/34416665/34416665 \
       -oh $ORACLE_HOME
    
    • 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.
    • Optionally, if I want a more graceful approach, I can manually stop the services, and perform draining.
    • opatchauto applies the patches to the GI home.
    • In the end, opatchauto restarts GI, including the managed resources (databases and the like).
    • opatchauto does not patch the database home.
  2. I connect to the other node, copenhagen2, and repeat step 1.

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

In my demo environment, each node was down for around 15 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.

Later on, I can patch my database.

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

Other Blog Posts in This Series

9 thoughts on “How to Patch Oracle Grid Infrastructure 19c Using In-Place OPatchAuto

  1. Hello Daniel,

    Thanks for the steps provided. Very useful.

    I am about to apply GI 19.18 patch in customer env. running 19.16.

    Should I go ahead with 19.18 or go with 19.17. (N-1) approach?

    Regards,
    Thiru

    Like

  2. Hello Daniel,

    Many thanks for the clear steps.

    I am reading this blog as I am about to apply GI patch in our Prod env. (still not live).

    For applying the latest opatch why do you delete the OPatch directory from Oracle Home?

    I do the following way, which I remember was the steps given in one of the MOS docs.
    It was mentioned in that MOS doc not to delete the original OPatch directory.

    e.g.,
    Download p6880880_190000_Linux-x86-64.zip in /u01/software
    $ cd /u01/software
    $ unzip -d /u01/app/oracle/product/19.0.0/dbhome_1/ p6880880_190000_Linux-x86-64.zip
    Enter A for All when prompted to overwrite
    $ cd OPatch/
    $ ./opatch version
    OPatch Version: 12.2.0.1.24

    Regards,
    Thiru

    Like

  3. Hi Thiru,

    You’re absolutely right. MOS recommends keeping the original OPatch directory. As long as you ensure the permissions are fine, you should be fine deleting/renaming the original directory.

    Regards,
    Daniel

    Like

  4. Hi Thiru,
    That’s a matter of preference. I understand the reason for both approaches. With the introduction of MRPs, I am more comfortable with the N-1 approach, because you can still get high profile patches in via the MRP.
    You also need to evaluate the security fixes in the latest RU. Perhaps there is a critical fix that you want to get in.
    Regards,
    Daniel

    Like

  5. Hello Daniel,

    Thanks for your response.

    I applied Patch 34762026 – GI Release Update 19.18.0.0.230117. in my Test Env. (19c 19.16 SEHA).

    I applied with the following command in Node 1
    (to apply both GI Home and DB Home patch together)
    :
    # $ORACLE_HOME/OPatch/opatchauto apply /_install/orasoft/grid_patch/34762026

    Patching went fine without any issues.

    But when I query the GI Home inventory I get this output:

    $ echo $ORACLE_HOME
    /u01/app/19.0.0/grid
    $ opatch lsinventory | grep 19.18
    Patch description: “ACFS RELEASE UPDATE 19.18.0.0.0 (34768569)”
    Patch description: “OCW RELEASE UPDATE 19.18.0.0.0 (34768559)”
    Patch description: “DATABASE RELEASE UPDATE : 19.18.0.0.230117 (REL-JAN230131) (34765931)”
    32652573, 31215854, 31185224, 32219318, 29700770, 30165892, 27453490

    Any idea why the output does not show ‘GI Release Update…….’. ? Why does it show “Database Release Update..” , Is this normal?

    Howz it in your environment?

    Regards,
    Thiru

    Like

  6. Hi Daniel,
    For years, we patch our RAC clusters with this “rolling method” and it works fine.
    However, I never used the -phBaseDir parameter, but it sounds interesting 🙂
    When you patch GI home and DB home in 1 operation with opatchauto, can you put the RU together with the DPBP in the -phBaseDir?
    Is opatchauto clever enough to apply DPBP only on DB home or will I have a conflict because DPBP is not a valid patch for GI home?
    Thanks for the information!

    Like

  7. Hi,

    The opatch tool can tell from a patch whether it is for GI or the database. It will skip patches if it doesn’t belong to the component being patched. You should be able to use -phBaseDir without problems.
    The GI/DB combo patch is a good example. It contains the GI patches and the DB Release Update in one patch file. OPatch applies the right patches to the right component.

    I encourage you to look at the new method for patching – switchGridHome. It is my personal favorite as it gives you more control and reduces risk.

    Regards,
    Daniel

    Like

Leave a comment