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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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
