Skip to Main Content
  • Questions
  • DB upgrade guidelines/ practices in enterprise applications

Breadcrumb

May 4th

Question and Answer

Connor McDonald

Thanks for the question, Sumit.

Asked: June 11, 2020 - 6:00 pm UTC

Last updated: July 13, 2020 - 5:33 am UTC

Version: Oracle 10G

Viewed 1000+ times

You Asked

Dear Team,

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.

Thanks.

Regards,
Sumit

and Connor 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.

Is this answer out of date? If it is, please let us know via a Comment

More to Explore

Administration

Need more information on Administration? Check out the Administrators guide for the Oracle Database