Re: Future of Oracle DBA - Man vs Machine

From: MacGregor, Ian A. <ian_at_slac.stanford.edu>
Date: Wed, 4 Oct 2017 16:03:54 +0000
Message-ID: <CY1PR0701MB1882F76746A056395C043B1EE2730_at_CY1PR0701MB1882.namprd07.prod.outlook.com>



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.

Ian A. MacGregor
SLAC National Accelerator Laboratory
Computing Division



From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Tim Gorman <tim.evdbt_at_gmail.com> Sent: Wednesday, October 4, 2017 8:20:08 AM To: knecht.stefan_at_gmail.com; verma.labs_at_gmail.com Cc: oracle-l
Subject: Re: Future of Oracle DBA - Man vs Machine

I think it was at Collaborate in the 2007 timeframe when the Oracle keynote (forget who) tried to announce "automatic upgrades and patching" as part of Enterprise Manager. He was literally booed by the entire audience of several thousand for a good 5-10 seconds, followed by derisive audience cross-chatter for another 30 seconds. I recall turning to the person next to me in astonishment, and she had the same incredulous look on her face. It wasn't because the technology was futuristic, it was because it was such a tone-deaf, naive, newbie thing to announce.

That was 10 years ago. I'm guessing that the people who experienced that feedback are mostly gone from product management now, and a new batch of fresh-faced young things just rediscovered the idea for the first time.

I don't think that anyone at Oracle has realized that patches, never mind patchsets and oh-my-god upgrades are *always* tested first, at least by anyone who wants to keep their job. As Stefan said, my first reaction would be to figure out how to disable it.

Initially, one might think that, as a cloud vendor, Oracle might have first-hand knowledge of operational requirements by now. But after you realize that cloud vendors write their own operational requirements and that customers have to live with them (not the other way around), it becomes easier to understand why such a feature might worm its way back into the product.

I recently heard someone use a great new verb: "dogfooding" (i.e. where one eats their own dog food). I'd like to see Oracle dogfood features like this on their own mission-critical internal systems (i.e. is their EBS GSI still running?) prior to trying to feed it to the world.

Long ago I heard someone wise say that Oracle software isn't ready for production use until it hits extended support; the market has certainly shared that view with Oracle12c Database.

On 10/4/17 01:00, Stefan Knecht wrote:
Well, personally I don't think there's much more to it than marketing noise at this point.

Automatic upgrades - well, sounds fancy, but who actually wants that? Upgrades needs to be tested, evaluated, tested again, etc etc... And well, obviously there's the downtime involved, which needs to be scheduled, and so on and so forth. Unless they have magically overcome the need to actually do any of those things I don't see that happening. It's been a long standing issue with "zero downtime upgrades" ever since Oracle started announcing it, what, 10 years ago? I still haven't seen one to date (it is somewhat possible using application technologies, but not database technologies). If you were to present me a database with "automatic upgrade"; my first question would be "how do I turn it off?".

Automatic patches / security updates is the same thing. And I kinda doubt they can actually do that, particularly because as of today they still need a full cluster outage to apply an OJVM PSU (maybe Larry forgot about those since they are already getting rid of Java IIRC?).

The self-tuning they have already introduced in 12.1 with the adaptive optimizer. And we've seen where that went. They've apparently now disabled some of it again in 12.2 by default since it simply didn't work as expected in live environments.

Automated backups, well, most of us would already have that won't we? We schedule them and from that point on they are running automated. The one thing that's needed is of course to validate the backups and do the occasional test and I highly doubt anyone would blindly trust automation in that area. At least not if you care about your business.

I think that at this point, nothing will change. The one thing to take away from it for me personally is that it indicates the general direction Oracle is heading, which sounds a bit like a "hands-free don't touch it" black box.

At least that's my THB 0.02 :)

Stefan

On Wed, Oct 4, 2017 at 12:07 PM, AMIT VERMA <verma.labs_at_gmail.com<mailto:verma.labs_at_gmail.com>> wrote: Hello Gurus,

I was looking át OpenWorld, in which Larry presented Oracle18c in which many of the Oracle DBAs tasks are automated like-

  • Database Automatically Upgrades
  • Applying Software Patches
  • Oracle Tunes itself while running
  • Automates security updates
  • Backing up of data
  • Less compute & storage because of ML & Automatic compression

After having 18c, The World first Autonomous Database than

  1. What will be future of Oracle DBA roles for the new learner & existing DBAs?
  2. Will Oracle guarantee 100% Autonomous Tuning, as we have observed many of the recommendation by existing tool even doesn't work in real production?

Look forward to your valuable time on this Man vs Machine.

--
Amit Verma
v.amit84_at_skype.com<mailto:v.amit84_at_skype.com>


"Winning takes talent but it takes character to keep winning"



--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net<http://zztat.net> | Support our Indiegogo campaign at igg.me/at/zztat<http://igg.me/at/zztat> | _at_zztat_oracle


--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 04 2017 - 18:03:54 CEST

Original text of this message