Reduce Production Downtime

 < Day Day Up > 



Many people are currently suggesting ways of minimizing your total downtime by upgrading a test file system and cloning that test system to upgrade production. This method would entail having a system to which you would clone your production instance and on which you would perform your entire upgrade (i.e., all patches, all drivers, everything required to get the system from the old version to the new version). Once the total upgrade was accomplished on this system, you would clone the middle tier to the production middle tier, apply all database and generate drivers to the new system, and proceed as you normally would.

While this may save considerable time in a 10.7 or 11.0 upgrade, I do not have the experience of having done a clone of one of these systems, so I do not know how long they would take. I do know that it generally takes around 8 hours to clone a minimal 11i instance to 11i instance and then (with adclone) you have some troubleshooting to take care of. If you are going to follow this track, I suggest making this the methodology you use through your entire upgrade process (upgrading all of your systems the same way). This will allow you to get comfortable with the process and will allow you to find as many of the opportunities as you can before you are faced with proceeding to production.

Upgrade Your Database to 9.2

While upgrading to Version 9.2 of the database is not necessary at this point, desupport for Oracle 8i has already been announced (although it is farther out for Apps users than for just database users). There are two thoughts on the upgrade of this now. It may be wise to wait until you have made sure that you have gone through a complete accounting cycle with your new 11i upgrade before you take this step, because this will add another 2 to 5 days to the production outage. However, it is a step that you will need to take in the foreseeable future. It can easily be done at this point, which will keep you supported and current and allow you to take advantage of many of the newer features on 9i. Plus you can minimize downtime with this, as well.

Install the new binaries in new ORACLE_HOME with similar structure, move the old one aside, and move this one into its place. This way you can install the binaries into their own home without having to take the database down and you can do your Apps migration at the same time. Although, you will want to have a good cold backup and all of your archive logs so if anything happens, you can recover. Also, you will want to make sure that you keep what is happening in what sessions on your server so you do not inadvertently do something in one session that you thought you were doing in another. I have seen this route taken with no ill effects to the running system. This also minimizes the effect on the front-end system. If there are no net changes to those file systems, you will have fewer problems in the upgrade.

Do not stop at 9.2.0; install the binaries and patch immediately to 9.2.0.2. This is recommended anyway and will get you to the supported release quicker.

Once your apps migration is finished, you can simply proceed to the Oracle 8i to 9i upgrade. While running U0801070.sql can take half of a day, because it is upgrading to 901 and then to 9202, it is relatively clean. You will also have to upgrade Intermedia, Intermedia Text, and Spatial. The steps to migrate these are in the documentation.

This upgrade is, for the most part, a simple database upgrade. You have to take into account spatial and the recompile of invalid objects. The recompile can error out, so you may need to up the amount of extents to unlimited in all objects. The running of the U0801070.sql invalidates nearly everything in the database. Running utlrp.sql (found in the ORACLE_HOME/rdbms/admin directory) can run for 13 hours or more. To make sure that you are still making progress, you can run the following query to make sure that the value returned is getting smaller.

 Select count (*) from all_objects where status = 'INVALID'; 

Migrate to Undo Tablespaces and Automatic Undo Management

With release 9i of the database, Oracle provides a mechanism for more elegantly managing undo and rollback information in the database. The mechanism is Automatic Undo Management and Undo Tablespaces. Implementing Automatic Undo Management means that you no longer have to monitor and tune the allocation of rollback segments. Although in 9.2, Oracle maintains Rollback Segment and Manual Undo Management for backward compatibility. How long they will remain supported remains to be seen.

To configure the database to run in Automatic Undo Management mode, you need to add two initialization parameters to the database as well as create an Undo Tablespace for the Automatic Undo Management to use. If the Undo Tablespace is not created when you attempt to use Automatic Undo Management, the database will not start.

 UNDO_MANAGEMENT=AUTO UNDO_TABLESPACE = apps_undo01 

You can optionally add another initialization parameter , UNDO_RETENTION, that tells the database how long to retain information in the Undo Tablespace. This is primarily used for flashback query. I do not think that flashback query is something that will be applicable in Oracle E-Business Suite in the near future, but in future releases it will become more and more applicable.

To create the Undo Tablespace reference above, you would issue the following command:

 CREATE UNDO TABLESPACE apps_undo01 DATAFILE '/ visdata/apps_undo01.dbf' SIZE 2000M REUSE; 

The only alter commands permissible with an Undo Tablespace are adding or renaming a datafile, bringing a datafile online or offline, or beginning or ending an open backup on the datafile.

If you find the need to switch Undo Tablespaces, make sure that there is a new Undo Tablespace defined and use the Alter system command to switch the Undo Tablespace (make sure that you make the change to the init file if you are not using SPFILEs):

 ALTER SYSTEM SET UNDO_TABLESPACE = apps_undo02; 

Remember, using Automatic Undo will not remove the possibility of Ora-01555 errors, but it will limit their occurrence.



 < Day Day Up > 



Oracle 11i E-Business Suite from the front lines
Oracle 11i E-Business Suite from the Front Lines
ISBN: 0849318610
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net