Such issues happen rarely, while sometimes we have to do such things.
If you can access the Oracle Support website, please read below notes:
Last time I run into this issue when I was installing Oracle 18.104.22.168 on the latest RHEL/SLES systems.
There are some huge differences between the latest RHEL/SLES and the previous versions, and the 22.214.171.124 was released many years ago so although such configurations are compatible and could be found on the Oracle Support website, the installation was a little different, and in fact I had to install several patches during the installation.
I will share the installation procedures in another post, and now just focus on one thing in it.
One word to summary:
"opatch auto" must NOT be used as the new GI home hasn't been configured yet.
When you read the readme file of the patches, most of them are for the configured ORACLE_HOME so you could not follow it, and you should install such patches in below ways:
- Install the software only, install the patch then configure the new ORACLE_HOME.
- Run the Installer in GUI mode, install the patch just before running the root.sh script, then run the root.sh.
The above are for the single instance, and for RAC databases you will have to clone the node except the first node.
Another thing is about the Oracle database version. Different versions have different way for such patch installation.
- <GI Home>/gridSetup.sh -applyOneOffs patch_location
<GI Home>/gridSetup.sh -applyPSU patch_location
- ./opatch lspatches
12.1.0.x or 11.2.0.x:
- Method 1: install GI with software only option, patch it then clone it to other nodes and configure the new installed GI homes.
- Method 2a: install it with GUI mode, when get prompt to run root.sh, do not run it directly but install the patch on EVERY node, then back to the normal process and run the root.sh script.
- Method 2b for 126.96.36.199: install the RAC as normal process and run the root.sh, then install the patch.
I will include such detail in another post.