RE: Upgrading with no patches in the "base"?

1. Clone production to your test machine environment and upgrade to the farthest forward RDBMS version you can access, all patched up.
2. Have your staff walk through their usual defined essential services interactive forms and queries to be certain the interactive part of the application works to their satisfaction (including training on new or changed functionality).
3. Perform your daily, weekly, quarterly, and annual batch regression tests on the clone.
4. When that all works, schedule doing the migration for your real production.

IF you reach a point where you cannot do 2 and 3 and no patches to resolve any problems seem to be forthcoming from the application vendor or the RDBMS vendor, only then consider moving to a point short of the latest.  

Good luck.  

mwf  

PS: Make sure that email, ach, e-transaction, and printer instructions for action (like build to order manufacturing instructions) all reach destinations that are understood to be test information rather than real. Otherwise hilarity ensues when you trigger the supply chain to order materials to build 100 aircraft carriers.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael Kline Sent: Friday, January 08, 2021 9:29 AM
To: 'ORACLE-L'
Subject: Upgrading with no patches in the "base"?  

Hearing that an application is going to be upgraded from 12.1 to 12.2.  

Vendor is saying they will create a “blank, no patched” 12.2 $ORACLE_HOME, and then upgrade the database.  

They will test this for a while, and if everything is fine, THEN they will apply the patch.  

I’ve never heard of such a thing and have been working on Oracle databases since 1983, version 4.0.  

Is there logic in this? We try to keep all databases at N-1 on patching.    

Michael Kline      

--
http://www.freelists.org/webpage/oracle-l