Re: Policy on Oracle Versions and Patches
Date: Fri, 10 Oct 2008 23:35:55 -0700 (PDT)
On Oct 10, 4:31 pm, ca111..._at_gmail.com wrote:
> I do have time to read release notes, in fact I read them very
> For example, in Release Notes for 188.8.131.52 on Lunix x86:
> Section 5.1.5:
> All databases that use any features of Oracle Streams must be upgraded
> to release 184.108.40.206 or later. Operation between release 220.127.116.11 and
> release 18.104.22.168 is not supported for databases using Oracle Streams
> Section 5.2
> Beginning with patch set release 22.214.171.124, INSO software is no longer
> shipped with Oracle Text
> Section 10.4
> In release 126.96.36.199 and earlier, the maximum number of cursors that
> could be cached for fast lookup by PL/SQL was bounded by the value of
> the OPEN_CURSORS initialization parameter.
> This tells me that Oracle introduced new features and what they call
> "behaviour" in patch sets.
> In fact we installed 10.2.0.4 recently and then had to switch back to
> 10.2.0.3 it as outer join returned wrong result.
> I also talk to Oracle Support on a regular basis and they tell me
> things like
> "The problems with subpools (of the shared pool) started around
> 10.2 does not seem to be stable, we had quite a few crashes
> (bloom_filter thing, ORA-00600 [kcbget_37], etc).
> I think stable versions are 188.8.131.52, 184.108.40.206, 220.127.116.11.
> Regarding "supported" - ask Oracle for password to download patch
> 2421054 for 18.104.22.168 on AIX 5L - officially this patch has been
> available since May 2008.
I'll throw in my $0.02.
A few notes first:
Section 5.1.5 refers to a very serious flaw that lead to kind of total redesign of Streams internal workings, thus initial Streams release that came with 22.214.171.124 is not interoperable with any subsequent releases, it was just plain broken in 126.96.36.199 as far as I remember.
Section 5.2 does not affect applications using the feature, it was a change of the underlying technology Oracle licensed from a 3rd party and they made every effort to ensure nothing will be broken by this change (and nothing was.)
Section 10.4 talks about a notable *enhancement* to the functionality that may affect resource consumption and performance, but does not otherwise affect the behavior of your applications.
Oracle reserves the right to deliver certain enhancements and behavior changes in patchsets, but isn't it true for any other software vendor? They just call it differently (service packs, fixpacks, patch clusters, whatever.) Patchsets undergo rigorous internal testing (unlike one-offs, which are quick fixes for very specific problems and are not tested for compatibility with other one-offs,) and should generally be considered as stable as base releases. Indeed, there are cases when patchsets introduced serious regressions or very notable behavior changes, but hey, nobody's perfect, and Oracle Database is one very complex product... That's why you should always do your own testing in your specific environment before rushing patches into production, and this rule applies not only to Oracle.
> 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
> - 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 188.8.131.52. 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.
> When you have "supported" hardware HP/Sun/IBM/EMC will replace broken
> part typically withing 24h. For "supported" version Oracle may produce
> patch in a month or two.
Your comparison between hardware and software support is incorrect - you're comparing bycicle to spacecraft here. Hardware is mass-produced and the only delay you get when replacing some broken part is logistics. Every software bug is unique and requires generally indeterminate amount of time to diagnose, understand, fix, test to make sure the fix is indeed a fix and that it doesn't break anything else, possibly backport to some previous release and test against that release, redo the fix or introduce additional changes elsewhere if conflicts are found, repeat until everything's working as expected, deliver to the customer, let them test and if something goes wrong in *their* environment then repeat the whole cycle again with newly discovered information... Quite a difference, isn't it?
> 2. Let's say you implemented new application using 10.2.0.3 as per
> vendor recommendations. During implementation the application
> functionality has been extensively tested.
> Would you automatically apply 10.2.0.4 even if nothing seems broken?
> Extensive application testing isn't possible.
In this particular case I would relay "extensive application testing" on the new patchset to the application vendor and wait for their recommendations (or their "certification" on this patchset.) ROT here is "if it ain't broken don't fix it."
Vladimir M. Zakharychev
N-Networks, makers of Dynamic PSP(tm) http://www.dynamicpsp.com Received on Sat Oct 11 2008 - 01:35:55 CDT