Upgrades Versus New Installations

In some respects, upgrades are more challenging than initial installations. On initial installations you often have to learn more than you ever wanted to know about Oracle and your operating system. However, people often are more understanding when you are asked to implement a new technology. Upgrades, on the other hand, are often looked on as just applying a few bug fixes. You also have to deal with people who are using your database for production purposes and who cannot tolerate a lot of down time. They often do not understand the time it takes to unload and relink the Oracle software. They almost certainly will be very upset if the new version of Oracle introduces bugs or causes applications to fail due to changes in functionality within Oracle. This section provides a few considerations for the upgrade process.

Other Factors to Consider

On most production systems, you do not have the luxury of switching back and forth between releases as you explore your new software. Always have a test instance, even if it is small, to test your new RDBMS release against your production applications before you even think about trying it on production.

The new features that are available with the new release are some of the first things that you should be considering. Many of these are internal to the database and of concern only to the DBA. Bug fixes are generally appreciated by all, but you may want to remove some work-arounds that you had made to keep the old release of the software going after you have tested the new release. You also may want to publish the list of new features and bug fixes to your developers. They often do not get their own copies of the Oracle documentation and therefore do not take advantage of the new features that may save them time and also save database resources. I always say that an informed developer is one who is not coming to you with questions all of the time.

You should also be especially sensitive about any features that were available in the previous release, but that are no longer available in the new release. Typically, Oracle works very hard to ensure backward compatibility, but in the release documentation you will find a few features mentioned that are being phased out. You should also publish these to developers and consider removing them from your own software (admin scripts and so forth) before it becomes a crisis.

The next factor to consider is that the new version may increase the amount of memory that you use. Some of this comes about when you take advantage of new features, such as additional background processes. Others creep in when you find that you need to allocate additional space for Oracle tunable parameters to support the new software. For example, I was very surprised at the increased number of cursors that Oracle 7.1 used. We had to increase the init.ora file setting for cursors by a factor of 100 to get our existing applications to work under Oracle 7.1. Who knows what Oracle 8.1 will hold compared with Oracle8? This was not bad in that it did not appreciably increase the amount of shared memory space used, but the principle should be considered. Always check the disk and memory requirements of your new software, along with other tuning suggestions in the installation documentation.

It’s always a good idea to clean up the instance before upgrading it. Perhaps it is just the mental attitude of wanting to have the instance “fresh” after the new installation, or perhaps it is the only time that you get to think about such things. Anyway, if you get the chance, clean out old, unwanted tables, indexes, and so forth. Although there is usually not a lot to do in a production instance, most development instances need this routine cleaning. Typically, I send a list of objects to the development manager and ask him to get his people to indicate which objects are still needed and which can be deleted. Some developers try to keep as much as possible, but when disk space is limited, you can use peer pressure to keep their tablespace free of clutter to support new projects.

Finally, even though the software goes through a reasonable test suite at the factory and at beta test sites, you should always plan to run a thorough test of your applications running against the new database software before making it available to users. You may discover that you are using features that are no longer supported and therefore you have to make some changes to your application software. You may find that your application finds a new bug in the Oracle software and you have to develop a work-around or get a patch from Oracle. Finally, your application may exceed the capacity of certain resources (like my cursors problem with Oracle 7.1). In this case, you have to adjust your tuning parameters until you get everything working happily again.

Send out the information to your developers so that they are better prepared for their development efforts. Many of these issues may not be applicable in your case. You may find that you are running only a packaged application such as Oracle Financials, and therefore you do not need to concern yourself with development issues.