Re: Patches !!!!

In article <akkkb9$e4a$1_at_babylon.agtel.net>, "Vladimir says...
>
>But how do you reliably determine if you need a patch? Proactively installing
>patches to prevent problems looks better than reactively patch bugs that already
>popped up and did some damage to your system (but in this case you can be
>absolutely certain you need the patch, and that's about the only case. For me,
>a better mantra would be 'always install the latest patches on your testbed
>first
>and verify that they didn't break anything, then install them on production and
>watch it closely. And don't forget to backup before you change anything.' I do
>not like 'If it ain't broken, don't fix it' mantra when it comes to critical
>patches -
>it will be way more expensive to recover from successul hack that succeed
>because you didn't install some critical patch than it will be to recover from a
>patch that broke something that was working before (especially if you first
>installed it on your test box).
>
>My $0.02.
>
>--
>Vladimir Zakharychev (bob@dpsp-yes.com) http://www.dpsp-yes.com
>Dynamic PSP(tm) - the first true RAD toolkit for Oracle-based internet
>applications.
>All opinions are mine and do not necessarily go in line with those of my
>employer.
>

Totally agree. But there's a world of difference between each of "install a patch because you need it", "if it ain't broke don't fix it", and "let's be cowboys and just throw everything into Production without testing it properly first". I still remember documenting why we should move from 6.0.34 to 7.0.13 - I ended up with a document over 100 pages on things to take advantage of and things to be extremely careful of (the CBO springs to mind as one of the latter in those days!)

The way I always did things like this when I was a real DBA instead of a consultant was to download patches that were for my OS and DB environment, and then extract the README file. I'd plow through that to determine:

1. What the patch fixed
2. What it broke

and then install into a DBA environment (precursor to Development, my play area only). Then pull back Production code for one of our apps, and test it out. When I was happy with the patch, then I'd organize a time with the developers to isntall the patch in Development (done overnight while the developers were all in bed), complete with keeping a backup of the kernel and the database as they were just before installation. Let the developers test it further (with the backup available for a quick restore if they found something I didn't). Then gradually move it through Acceptance Testing into Production.

It took a long time to migrate a patch through, but after being burnt badly with some patches was back in the 6.0 days, at least we didn't have the interruptions to business that we had had sometimes in the past.

Pete
>
>"Pete Sharman" <peter.sharman_at_oracle.com> wrote in message
>news:akjonk02sb4_at_drn.newsguy.com...
>> In article <Lscb9.9850$xc2.1070284_at_news0.telusplanet.net>, "Terry says...
>> >
>> >Uh, patches that break your system perhaps? Yes, I've had a few Solaris
>> >patches that caused us tons of grief.
>> >Patching for patching sake is not wise.
>>
>> THat's obviously not a problem you've run into with Oracle patches! ;)
>>
>> Seriously, I totally agree with you. "Install a patch because you need it"
>> seems like a sensible mantra to me.
>>
>> Pete
>> >
>> >--
>> >Terry Dykstra
>> >Canadian Forest Oil Ltd.
>> >"Daniel Morgan" <dmorgan_at_exesolutions.com> wrote in message
>> >news:3D6D4C84.C311D9B4_at_exesolutions.com...
>> >> Rahul wrote:
>> >>
>> >> > Hi Guys,
>> >> >
>> >> > I am trying to install oracle 8.1.7.2 on Solaris 8 ( intel )...Do i
>> >> > need any patches or it should be ok w/o them..
>> >> >
>> >> > Thanks..
>> >> > Rahul M.
>> >>
>> >> You will likely be fine. But that is hardly adequate criteria. You
>> >> should definitely get the latest patches.
>> >>
>> >> I keep wondering why anyone would ask a question like this. To what
>> >> possible end could someone want to not have the most recent patch set? A
>> >> desire to have bugs? A desire to have poorer performance? A desire to
>> >> not fix security holes? Why?
>> >>
>> >> Rant over .... GET THE PATCHES!
>> >>
>> >> Daniel Morgan
>> >>
>> >
>> >
>>
>> HTH. Additions and corrections welcome.
>>
>> Pete
>>
>> SELECT standard_disclaimer, witty_remark FROM company_requirements;
>>
>

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Thu Aug 29 2002 - 11:06:26 CDT