Re: Upgrade issues 11.2.0.3 to 11.2.0.4?
Date: Tue, 31 Mar 2015 19:06:03 -0400
Message-ID: <CAAaXtLCdjnbDi_VUGwfpj3uxBdCKz_mYzDuxobO+hd4Fud3-sw_at_mail.gmail.com>
On Tue, Mar 31, 2015 at 1:09 PM, Seth Miller <sethmiller.sm_at_gmail.com> wrote:
> *"I consider this to be quick and dirty fix, which means that the upgrade
> was not conducted properly and that not enough testing was done."*
>
> So, if the application code was poorly written by a third party vendor
> leaving the customer no way to fix it, it's the customer's poor upgrade
> skills and lack of testing that are to blame for being forced to disable
> optimizer features.
>
> ...
>
Is this completely fair? Certainly, it is *impossible* to test a new patchset well enough to remove all possibility of "surprises" after an update. Its a risk we face and have to accept.
But with good testing, we should usually *know* that the "surprises" are coming. We then have the option of deferring the patchset until the application vendor fixes their code, or applying our own "cheap and dirty" workarounds. Neither option is perfect, and neither is always correct.
At the very least, we should probably be somewhat embarrassed when bad things happen following an update. But then, I bet few of us actually have the time/budget to do all the testing we would like to.
I have been engaged in a discussion on another forum concerning how many databases a small group of DBAs can manage. Some say the answer is "one", while I say the answer is -- or can be -- "hundreds". But 5 DBAs are not going to manage 200 or 300 databases if they all need to be patched once every 90 days, and we need to do 2 weeks of testing for each one prior to patching. (And some would say that "only" two weeks testing is wholly inadequate.)
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Apr 01 2015 - 01:06:03 CEST