Re: Future of Oracle DBA - Man vs Machine

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