Re: Policy on Oracle Versions and Patches
Date: Sun, 12 Oct 2008 10:25:33 -0700 (PDT)
Message-ID: <10112c52-fc1b-4d24-b609-ec843e7a5d30@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. 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)
http://www.dynamicpsp.com
Received on Sun Oct 12 2008 - 12:25:33 CDT