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@xxxxxxxx> 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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Tim Hall
Sent: Thursday, October 05, 2017 10:38 AM
To: Hemant K Chitale
Cc: knecht.stefan@xxxxxxxxx; tim.evdbt@xxxxxxxxx; MacGregor, Ian A.;
oracle-l; verma.labs@xxxxxxxxx
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@xxxxxxxxx> wrote:
How confident are those in the Oracle Database Core Development teamIsn't
(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.
permission.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
patches are much more loose than those of an OS.If once the DBA deigns that the system is ready, and these thingsIt's an interesting point, but I think there is a fundamental
happen without outages this is a good thing.
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
automatic patch".
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
and without me being able to test it first? Uhhhh Nope. Nope, nope, nope.
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",
Framework!
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
--Visit us at zztat.net | Support our Indiegogo campaign at
igg.me/at/zztat
| @zztat_oracle
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
