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@xxxxxxxxx> wrote:
On Wed, Oct 4, 2017 at 11:03 PM, MacGregor, Ian A. <ian@xxxxxxxxxxxxxxxxx>
wrote:
Minor patches to Linux operating systems are done automatically. Isn'tin patching an operating system vs patching a software as sensitive and
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
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
| @zztat_oracle
