Re: Future of Oracle DBA - Man vs Machine

This sounds like a pluggable module for OEM. They already have plugins to patch and such from the GUI. It helps in alot of cases. Oracle needs to automate more to compete with Amazon. It also looks like its mainly geared towards their cloud. Automation lowers cost. If they can't automate they can't compete with Amazon. I think most of these new features are designed to get people on the Oracle cloud. I work for a hosting company that has cloud (not amazon). We host alot of oracle. We dont host oracle in 'cloud' due to oracles price increase, but we host everything else on cloud. We host alot of Oracle on bare metal servers.

As an example of automating installs, I had to do 50+ RAC installs my first 2 years with the company. Hosting company. Lots of customers. We have to run installs in silent mode with a response file due to data centers all over the world, the GUIs are too slow. The documentation for the response files is absolutely awful... once you figure it out you can make a template. I found I only need to change 4 parameters for a GRID install and up to 2 parameters for an Oracle home install. Response file installs run much faster too. This has since been automated with a GUI interface. The hardware is standardized. So basically the operator (its not a DBA anymore) just uses a GUI. Enters the servers and hits run. DBAs then come in and follow an order to create the DBs, add the additional ASM disk per customer specifications, etc..

Automating upgrades is just DBUA in silent mode. Yeah you can have errors. I had issues with a 12c upgrade recently and had to go to support. Unlike amazon we basically allow whatever customization a customer wants if they pay for the extra support. However, most customers just want the lowest price so they will settle for defaults and a few options. Kind of like buying a Laptop from Dell. This is even more so for mySQL plus most other cheaper DBs. Only a few customers need a higher level of support.

Customers want as a low of a price as possible. Very small expenses are too much money. Even to big companies. Amazon started a race to the bottom on price. If we dont get customers, I dont have a job. They also want stuff done fast. My company wants the DBA team to manage as many DBs as possibles for as few DBAs as possible. If I want to keep my job, we have to get the price down to get more customers to compete with Amazon. Oracles price increase on Oracle cloud doesn't help, so my team is expanded into alot more DBs outside of Oracle such as Sybase, DB2, and noSQL DBs, there is an SAP team that we work with for DBs that host SAP, etc.. Plus they will start selling support for DBs hosted at Amazon since Amazon since Amazon doesn't 'yet' offer that level of DBA service. There are other companies that do that. To scale to large numbers of customers you have to automate to keep prices down.

On Thu, Oct 5, 2017 at 1:56 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:

> Mostly I agree with Tim. Please don't lose that sentiment when I point out
> that SQL Plan Baselines don't really apply to ad hoc queries. If a change
> causes a tendency for ad hoc plans that did at least okay before to mostly
> land in the dumper, that is a problem.
>
> If there is a quasi-magical way to have SQL Plan Baselines or any variety
> of profiles type technology apply to ad hoc (which includes generated
> queries from applications that haven't exactly been run before and saved as
> Baselines), then I missed that memo and would be joyfully corrected.
>
> mwf
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Tim Hall
> Sent: Thursday, October 05, 2017 10:38 AM
> To: Hemant K Chitale
> Cc: knecht.stefan_at_gmail.com; tim.evdbt_at_gmail.com; MacGregor, Ian A.;
> oracle-l; verma.labs_at_gmail.com
> Subject: Re: Future of Oracle DBA - Man vs Machine
>
> Hi.
>
> A collective response to several points raised over the last few emails...
>
> RE Linux: "Larger changes require a reboot to pick up a new kernel."
> No. That's what ksplice is for. You can apply kernel changes without a
> reboot. If you run on any server on Oracle Cloud you have Ksplice by
> default. You can stay fully compliant without reboot. If you run on-prem or
> on another cloud you can pay support for Oracle Linux and get ksplice.
> Oracle have servers that haven't rebooted for years but are fully up to
> date.
>
> RE: "All it takes is for a single plan to flip"
> SQL Plan Baselines stop this. Free in all editions in 18c. License change
> will probably be backported to older versions. For the vast majority of
> cases the problem of keeping consistent plans was solved a long time ago.
> The only reason for not having consistent plans is lack of knowledge of the
> product, or an unwillingness to pay for the feature, which is now free.
>
> The Autonomous suite of database services, of which the DW one is the
> first, will not suit everyone, which is why Oracle and other Cloud
> providers give you multiple services, as well as the ability to run
> on-prem. You don't have to use it, but it is worth considering.
>
> The service is built on top of Exadata. Since 18c allows rolling patches
> of everything, including OJVM, you can patch and stay online.
> (their words not mine)
>
> I share many of the same concerns that people here do, but I would love
> this stuff to work as I'm sick of doing the bullshit tasks or having to
> automate them myself. I would love someone to take them off my hands for
> Oracle, SQL Server and MySQL, so I can focus on more interesting issues.
>
> Cheers
>
> Tim...
>
> On Wed, Oct 4, 2017 at 11:28 PM, Hemant K Chitale <
> hemantkchitale_at_gmail.com> wrote:
> > 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
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

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