Thanks for the question, Sumit.
Asked: June 11, 2020 - 6:00 pm UTC
Answered by: Connor McDonald - Last updated: July 13, 2020 - 5:33 am UTC
Category: Database Administration - Version: Oracle 10G
Viewed 100+ times
As in any enterprise application, we have many in-house developed Microsoft.NET applications that connect to a central DB, Oracle 10G in this case. We have many web-services based on REST/ SOAP, Microservices, Oracle Reports, small tools and utilities, batch-jobs, web-applicatons (IIS hosted) and one big Windows based application in this environment.
We plan to upgrade Oracle to 18C in such an environment. The applications need to be upgraded with Oracle client code so that they can connect to the newer version of Oracle. We are not planning any changes in schema for the upgrade.
Our plan is to upgrade all the dependent applications in lower environment- update the oracle client code to handle new version. Once all the applications and oracle reports are migrated in development environment, we will start moving to higher environments such as UAT, INT, PERF, Pre-Prod and Prod.
In non-prod environments (other than Prod and non-Prod), we can directly switch from one version of Oracle to another because we have multiple instances such as UAT1, UAT2, INT1, INT2, etc. However, doing so in Pre-Prod and Prod is neither possible nor advisable. We may need to do a parallel run before we switch off the old DB.
In this regard, can you suggest good practices that we should follow for upgrading the applications in lower environment and also what strategy is better suited for prod environment.
and we said...
A few things worthy of note
a) Upgrading to 18c is a bad idea, because you'll be upgrading again in no time for support reasons. Go to 19c and you wont have to upgrade again until late 2020s
b) your non-prod mechanism looks sound to me.
c) for production, ultimately there comes a point where you need to switchover, and also have a decision point at which it is no longer possible to go back. Typically for the latter, it is the moment you start taking transactions from customers, because the public relations disaster of failing back and losing their transactions is too great. So a typical scenario is:
- announce outage
- upgrade/migrate etc
- open system for testers/run through some sample activities/ensure basic system functionality is all working
- then go live for real
- react and fix any issues encountered
A *genuine* parallel run, where you take live transactions against both environments is a big jump in complexity because you're now looking at an active-active GoldenGate operation or similar...Often that is not worth the effort.
When you do upgrade, ensure that you do not alter the "compatible" parameter, because the moment you do that, there is no going back at all. If you leave it at 10, then during the entire upgrade process, if something went horribly wrong, you can fail back to your 10g database with just a few scripts. Once that compatible parameter is moved up to 19 (or anything > 10) then that fail back is no longer possible without full database restore.
But I stress ... go to 19c.