RE: Upgrade Plans

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.

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).