Re: Policy on Oracle Versions and Patches

From: Palooka <>
Date: Sun, 12 Oct 2008 22:24:35 +0100
Message-ID: <5WtIk.136$Ab4.118@newsfe15.ams2>

Vladimir M. Zakharychev wrote:
> On Oct 12, 8:06 pm, "Bob Jones" <em..._at_me.not> wrote:

>> "Vladimir M. Zakharychev" <> wrote in
>> On Oct 11, 6:30 pm, "Bob Jones" <em..._at_me.not> wrote:
>>>> 1. What version/patch level should be used for implementing brand-new
>>>> application assuming that:
>>>> - Is it critical
>>>> - Application vendor didn't provide any recommendation regarding
>>>> version
>>>> - Schema is simple, it does not use any advanced features
>>>> - Main priority is stability and absence of unplanned outages
>>>> It seems to me that the safest option would be to use version that has
>>>> a terminal patch set which is Yes I know that it is
>>>> "unsupported" but does it really matter?
>>>> When starting anew, I'd go with the latest release available and test,
>>>> test, test, find bugs, report them to the vendor, to Oracle, and get
>>>> them fixed before you go live.
>>> If I followed this suggestion, I would have gone to 10g when it first came
>>> out, and not go live until all the bugs are fixed. That would be a good
>>> idea
>>> if I could convince the mangement to schedule our go-live dates according
>>> to
>>> Oracle's patch dates, or better yet become Oracle's beta test site.
>>> I didn't mean *all* bugs, but all those directly affecting you. What
>>> will you do if you start with a terminal release and hit a bug in it?
>>> It's terminal meaning no more patchsets are going to be delivered, so
>>> you will be forced to either apply one-offs (which are not thoroughly
>>> tested by definition and may break other things,) or upgrade. Oracle
>>> fixes bugs in the current trunk first and then backports them to
>>> previous release branches as needed/possible (and I remember seeing
>>> fixes that could not be backported at all.) Generally it means that
>>> all Oracle releases/patchsets current as of the date of
>>> release include the same fixes for common functionality (though of
>>> course there are numerous exceptions.)
>> Hitting a bug on a terminal release is much more unlikely than the first
>> release, especially the critical ones. Most bugs would have been fixed after
>> terminal release.
>> There is no way to know when Oracle will fix all the bugs directly affecting
>> me. Like the other gentleman said, it could be the next patch or the next
>> release. For many of us, go-live is an all important event. You don't just
>> postpone it because of an Oracle patch.

> Hitting the same bug on terminal release is just as likely as on the
> next release because they share a good portion of the core code,
> especially if you are not using functionality new to the next release.
> And you can deliberately switch off that new functionality or behavior
> changes by setting the compatible parameter. The difference is that
> for terminal release you will not get a fully tested and integrated
> fix, just a quick one-off.
> I know many people these days tend to take the conservative approach
> and adopt new releases "after the second service pack is out,"
> actually I am one of them, but for new projects we tend to start with
> the latest release because we can always move to some previous release
> if something goes wrong in the current release and there is no quick
> remedy. The trick is to avoid using newly introduced features without
> very extensive testing: allows you to step back to an earlier release
> if this new feature is buggy, or stay with the new release and use the
> feature if it really works for you. Indeed we're wearing beta tester
> hats for Oracle here, but the end result is that we get things working
> the way we want and other people get more stable product without
> negative experience from their side in form of more comprehensive
> patchsets. "Somebody's got to be unafraid to lead the freak
> parade." :)
> Regards,
> Vladimir M. Zakharychev
> N-Networks, makers of Dynamic PSP(tm)

That makes a lot of sense. If this is a new application, start with the latest patch release and go from there. Otherwise, the client will have to pay all over again for regression testing for the next release - or take a chance on a one off patch.

I'm putting in a new application on, with all the latest CPUs and recommended patches, because testing hasn't started in earnest yet. Ideally I'd have started with 11g, but the application vendor did not certify it in time.

The thought of installing on did not occur - what is the point of using a near end-of-lifecycle product, where the team will have to test all over again for the next Oracle upgrade? And as Vladimir says, just because it is a terminal release doesn't promise that is bug free.

Palooka Received on Sun Oct 12 2008 - 16:24:35 CDT

Original text of this message