Re: Did you once had to back out from an CPU implementation?

From: bdbafh <bdbafh_at_gmail.com>
Date: Wed, 16 Apr 2008 08:52:37 -0700 (PDT)
Message-ID: <27ef4140-a7a7-4d34-83a1-881cbddf1a6c@b1g2000hsg.googlegroups.com>


On Apr 16, 11:36 am, Helma <helma.vi..._at_hotmail.com> wrote:
> Hi all,
>
> More a question of curiosity, but did you ever had to undo a CPU
> implementation? I've run across shops who
> a) never applied CPU's
> b) applied them without testing and
> c) read the documentation to check if the cpu is relevant to them and
> any side-effects before installing.
>
> Now working at a 'c)' company, what are your experiences in this
> field ?
>
> Helma
> (secretly hoping to hear horrorstories) ;)

Helma,

No real horror stories to report, sorry. I did have to back out a one-off patch.
The database wouldn't open due to an AQ error. The error was not encountered in testing of a clone of the database on a server that was the same hardware, os, service pack, OS hotfixes, etc.
Had backing out the patch not worked, the backup set taking prior to applying the patch would have been restored and recovered. That was one case in 10 years covering numerous systems.

If you don't have spare hardware to test on, create a new home, apply the patch there, clone the database and test it out on the server that you do have.

The most important thing is to have a plan as to how to fall back to a point prior to applying the patch. The second most important thing is to follow the readme.htm (proper settings for init.ora params: shared_pool_size, java_pool_size, use the correct version of opatch). Third would be post-apply testing. Having no errors and invalid objects after running utlrp.sql is good, but not sufficient. Having someone else test the app afterwards with non-privileged accounts will find errors such as leaving the database instance in restricted session (D'oh!).

-bdbafh Received on Wed Apr 16 2008 - 10:52:37 CDT

Original text of this message