Q
Manage Learn to apply best practices and optimize your operations.

Speeding up the startup migrate process during upgrade

We are not allowed any downtime in order to upgrade from Oracle 9.2.0.4 to Oracle 9.2.0.6. Our plan is to install Oracle in a separate Oracle Home and patch it to Oracle 9.2.0.6 on each node in the cluster. We would then shut down the active instances, switch Oracle Home to the 9.2.0.6 and startup migrate. My question is can you think of any way that we could speed up the startup migrate process?

My client has stipulated that we are not allowed any downtime in order to upgrade from Oracle 9.2.0.4 to Oracle 9.2.0.6. We are running 4-way Oracle RAC in a Sun Cluster 3 environment on F15K hardware. We also have a physical standby database at another site. We cannot use logical standby for various reasons, and we cannot afford the extra 20 to 30 terabytes of storage this would require.

Given that Oracle does not provide a rolling upgrade for patchsets, we are therefore forced to have downtime. Our plan is to install Oracle in a separate Oracle Home and patch it to Oracle 9.2.0.6 on each node in the cluster. We would then shut down the active instances, switch Oracle Home to the 9.2.0.6 and startup migrate. My question is can you think of any way that we could speed up the startup migrate process, perhaps trimming some of the unecessary steps out of the catpatch scripts? Aside, that is, from deleting statistics from the SYS schema, we have not been able to think of any other ways of speeding up the process.

It's always a balancing act when upgrading high availability systems. You need to accelerate the upgrade, yet do it in a safe manner. Your approach is a valid one – I personally prefer this phased method of upgrading. The one thing to be cautious of is that you do this without corrupting your Oracle inventory. If your inventory does become corrupted during this process, it will surely make applying future patches and upgrades an even bigger headache.

Another approach to consider is to rename your oraInventory subdirectory and/or change the location of the oraInventory in the oraInst.loc file. Install Oracle 9.2.0.4 into another ORACLE_HOME and leave it at this version. During a quick outage, simply point the existing database to this ORACLE_HOME. Nothing will have changed, yet the database is still at version 9.2.0.4.

Change your oraInst.loc file back and/or rename your oraInventory subdirectory back to what it was. Upgrade the original 9.2.0.4 binaries to 9.2.0.6. During the next outage, point the database to this newly upgraded ORACLE_HOME and complete the upgrade process on the database side.

This will mean two outages on your production system but it also allows your inventory to remain complete and accurate so that future security patches (or other one-off patches) will be able to read and update the inventory. You also have the benefit of keeping a generically named ORACLE_HOME, e.g., /oracle/product/920 rather than /oracle/product/9206.

Before you do any of this on the production system, I can't stress enough the importance of testing this on a non-production system several times. This will let you know whether you will experience inventory problems or not, and whether your approach will work as expected.

With respect to your question about modifying catpatch.sql, I would not recommend doing this. While it may (or may not) accelerate your upgrade, it won't be worth it if you encounter unexplained problems weeks or months down the road.

Dig Deeper on Oracle database installation, upgrades and patches

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide.com

SearchDataCenter

SearchContentManagement

SearchHRSoftware

Close