Re: Upgrade issues 11.2.0.3 to 11.2.0.4?
- From: MARK BRINSMEAD <mark.brinsmead@xxxxxxxxx>
- To: Seth Miller <sethmiller.sm@xxxxxxxxx>
- Date: Tue, 31 Mar 2015 19:06:03 -0400
On Tue, Mar 31, 2015 at 1:09 PM, Seth Miller <sethmiller.sm@xxxxxxxxx>
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.)
Other related posts:
