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:
- Latest OPatch from My Oracle Support (6880880).
- 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.
-
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 -
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 -
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_HOMEset 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.
-
First, as root on copenhagen1, I use
opatchautoto 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.
opatchautoapplies the patches to the GI home.- In the end,
opatchautorestarts GI, including the managed resources (databases and the like). opatchautodoes not patch the database home.
-
I connect to the other node, copenhagen2, and repeat step 1.
- You must proceed as quickly as possible.
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
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 Grid Infrastructure 19c Using Zero Downtime Oracle Grid Infrastructure Patching
- 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
- 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
Databases Are Fun 
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
LikeLike
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
LikeLike
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
LikeLike
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
LikeLike
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
LikeLike
Hi Thiru,
The patch “OCW …” is the Release Update for Grid Infrastructure. OCW = Oracle Clusterware.
Regards,
Daniel
LikeLike
Hello Daniel,
Many thanks for your response.
Regards,
Thiru
LikeLiked by 1 person