Re: Future of Oracle DBA - Man vs Machine

How confident are those in the Oracle Database Core Development team (not referring to the VPs/SVPs reporting to the CxOs) ? Can they deliver automated patching that doesn't cause plan flips on critical SQLs (and each application / implementation has a different list of critical SQLs) or any outages ?

Hemant K Chitale
Sent from my smartphone

On 5 Oct 2017 13:47, "Stefan Knecht" <knecht.stefan_at_gmail.com> wrote:

>
>
> On Wed, Oct 4, 2017 at 11:03 PM, MacGregor, Ian A. <ian_at_slac.stanford.edu>
> wrote:
>
>> Minor patches to Linux operating systems are done automatically. Isn't
>> this bringing that same methodology to database executables. Larger
>> changes require a reboot to pick up a new kernel. I have to think the
>> database won't apply patch sets or upgrade itself without permission.
>> If once the DBA deigns that the system is ready, and these things happen
>> without outages this is a good thing.
>>
>>
>> It's an interesting point, but I think there is a fundamental difference
> in patching an operating system vs patching a software as sensitive and
> sophisticated as the Oracle database. Yes, of course system calls may
> behave somewhat differently under the hood , but the odds that some
> specific behavior fundamentally changes is significantly lower when you're
> patching the OS. The system call that gets patched still has to adhere to
> the standards and documentation, it still has to return the same data.
> Oracle has much more leeway there since the bulk of the database's
> functionality isn't documented. The boundaries within Oracle can change
> things during patches are much more loose than those of an OS.
>
> I am personally very strongly against anything automatic that potentially
> impacts the functionality and usability. Look at Windows 10 for a good
> example what automatic updates can do: data loss. I've had to adjust my
> personal behavior ( I can't safely let the computer run over night with
> applications opened and assume that it will still be there in the morning
> like I used to). Imposing, or forcing, something along those lines on
> Oracle's database customers in the cloud, oh boy I truly hope they don't go
> down that road. Just imagine the headlines "Major Oracle-Cloud hosted
> website out for 8h due to automatic patch".
>
> I think overall a database is much more sensitive to software changes than
> an operating system. All it takes is for a single plan to flip, and all
> hell will break loose. And there's literally thousands of things that can
> potentially cause a plan to flip - the constantly-growing list of optimizer
> underscore parameters, the numerous different functions involved in
> statistics gathering, the optimizer itself and the hundreds of decisions it
> makes when producing an execution plan. Just thinking about leaving all
> that at the grace of your cloud provider to change all that,
> "automagically", and without me being able to test it first? Uhhhh Nope.
> Nope, nope, nope.
>
> Don't get me wrong, I'm not saying OS patches aren't equally important and
> can't cause any issues. Many shops carefully plan and test their OS patches
> as they do their database patches, which in my opinion is the right way to
> go about it.
>
> Automation is fine, so long as it's within clearly defined boundaries that
> I can control. <shameless plug> such as my new framework zztat, where I can
> control under what circumstances exactly the database will be adding new
> data files automatically, or will collect detailed latch data automatically
> when there is a contention so I don't have to do this manually at 3 AM.
> That sort of automation I am a big fan of. Because the odds that the
> outcome makes my life easier are far greater than the odds of me loosing my
> job over it :) </shameless plug>
>
>
> Stefan
>
>
>
>
> --
> //
> zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
> Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat
> | _at_zztat_oracle
>

--
http://www.freelists.org/webpage/oracle-l