Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Upgrade Plans

RE: Upgrade Plans

From: DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
Date: Wed, 24 Sep 2003 08:44:44 -0800
Message-ID: <F001.005D0EFD.20030924084444@fatcity.com>


Ken

    Having gone through this numerous times, I don't think there is such a thing as a detailed plan that has any use beyond the immediate task. I would concentrate first of all on your philosophical approach, the principles on which you work. Here are some ideas:
- Create a staging/QA server for each production server that is identical
as possible to production. I like to create the Oracle database from backups so I get a chance to verify my backups at the same time.
- Have a complete set of data for the staging database. I've seen several
problems that were not replicated with only a portion of the data.
- Perform the exact steps in staging that you will be performing in
production and take careful notes. Repeat if any problems are encountered.
- Always have a backout plan for any production action. I find a lot of
comfort in a cold backup of the entire system.
- As much as possible, change only one component at a time. That is, only
upgrade the O.S., give the system a few weeks to shake out, then upgrade the DB, and so on. Then when a strange problem arises you know which vendor to go to first.
- Stick to versions certified by the vendors. Only use an Oracle version
certified for that version of the O.S. and application.
- Decide your approach to applying patches. Typically patches are tested
much less thoroughly than overall releases. So some sites only apply patches if they are experiencing problems the patch will fix. Other sites believe in applying all patches as soon as they are released.
- Then there will be a bunch of steps related to your specific situation.
All I know is to get as many people involved as possible to minimize the chance that something is overlooked. And if something does get overlooked, people won't get nearly as upset if you kept them in the loop so they had a chance to raise issues as if you left them out.
- Promise the users that the downtime will be more than you expect. Better
to underpromise and overperform.

-----Original Message-----
Sent: Wednesday, September 24, 2003 9:25 AM To: Multiple recipients of list ORACLE-L

Would like to know where I can find some detailed plans on upgrading server, O/S, DB and applications to their new releases. Something like a TO DO list would be helpful. Any help will be greatly appreciated.  

Thanks much,
Ken Janusz, CPIM

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Wed Sep 24 2003 - 11:44:44 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US