Re: Policy on Oracle Versions and Patches

From: Bob Jones <email_at_me.not>
Date: Sun, 12 Oct 2008 17:32:50 -0500
Message-ID: <lWuIk.3402$c45.699@nlpi065.nbdc.sbc.com>

"Vladimir M. Zakharychev" <vladimir.zakharychev_at_gmail.com> wrote in message news:10112c52-fc1b-4d24-b609-ec843e7a5d30_at_34g2000hsh.googlegroups.com... On Oct 12, 8:06 pm, "Bob Jones" <em..._at_me.not> wrote:
> "Vladimir M. Zakharychev" <vladimir.zakharyc..._at_gmail.com> wrote in
> messagenews:98885e17-974f-4d1b-adac-cad2babff9e3_at_l76g2000hse.googlegroups.com...
> 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 9.2.0.8. 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 9.2.0.8
> > 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.

Perhaps, but just the new features being there can cause issues. You don't even have to directly use them. Some new features actually replace old ones. We have to use them whether we are ready or not.

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

This only guarantees backward compatibility with external applications. The database internals are still on the new release. Upgrades not only add new functionalities, there are also "maintenance improvements" over existing features.

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

There are good reasons not to be on the bleeding edge if downtime is being measured by minutes.

If you are at the early stage of development, downgrading the database is ok. If you are near go-live or mid way through a project, it can mean a delay or a disaster.

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

I am afraid this trick will not always work for the reasons I stated above.

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

Maybe you are not afraid to lead the parade into a million-dollar downtime. The last thing I want to do is spending all that time dealing with bugs that can be avoided. Received on Sun Oct 12 2008 - 17:32:50 CDT

Original text of this message