Given that Oracle does not provide a rolling upgrade for patchsets, we are therefore forced to have downtime. Our plan is to install Oracle in a separate Oracle Home and patch it to Oracle 18.104.22.168 on each node in the cluster. We would then shut down the active instances, switch Oracle Home to the 22.214.171.124 and startup migrate. My question is can you think of any way that we could speed up the startup migrate process, perhaps trimming some of the unecessary steps out of the catpatch scripts? Aside, that is, from deleting statistics from the SYS schema, we have not been able to think of any other ways of speeding up the process.
Another approach to consider is to rename your oraInventory subdirectory and/or change the location of the oraInventory in the oraInst.loc file. Install Oracle 126.96.36.199 into another ORACLE_HOME and leave it at this version. During a quick outage, simply point the existing database to this ORACLE_HOME. Nothing will have changed, yet the database is still at version 188.8.131.52.
Change your oraInst.loc file back and/or rename your oraInventory subdirectory back to what it was. Upgrade the original 184.108.40.206 binaries to 220.127.116.11. During the next outage, point the database to this newly upgraded ORACLE_HOME and complete the upgrade process on the database side.
This will mean two outages on your production system but it also allows your inventory to remain complete and accurate so that future security patches (or other one-off patches) will be able to read and update the inventory. You also have the benefit of keeping a generically named ORACLE_HOME, e.g., /oracle/product/920 rather than /oracle/product/9206.
Before you do any of this on the production system, I can't stress enough the importance of testing this on a non-production system several times. This will let you know whether you will experience inventory problems or not, and whether your approach will work as expected.
With respect to your question about modifying catpatch.sql, I would not recommend doing this. While it may (or may not) accelerate your upgrade, it won't be worth it if you encounter unexplained problems weeks or months down the road.
Dig Deeper on Oracle database installation, upgrades and patches
Related Q&A from Maria Anderson
I have been trying to install Oracle 8.1.7 on SUSE Linux 9.0 and got the error: "Error in invoking target install of makefile /opt/oracle/...../*.mk." Continue Reading
I'm getting errors while installing the Database Configuration Assistant. Continue Reading
Can I use /var/opt/oracle/oratab to specify listener information? Continue Reading