„Operational DBAs“ are dying species irrespective of the latest Oracle
development. Efficient organizations have been automating tasks anyway and in
doing so, have already eliminated the need for full time “operational DBAs”. In
such teams, the advanced DBAs (in some organizations they are called “DB
engineers”) share not-yet-automated tasks instead, to stay connected to the
production reality. Furthermore, as Mladen has already mentioned, they are
cultivating general knowledge which enables them to make stronger impact on the
organization.
I elaborated on that here: http://nenadnoveljic.com/blog/google-sre-database/ ;.
Nenad
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mark W. Farnham
Sent: Mittwoch, 4. Oktober 2017 15:09
To: gogala.mladen@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Future of Oracle DBA - Man vs Machine
+1
As early as 1990 a group of companies I was a part of (Oracle VLDB and later
MOSES) was trying to define the difference between “operational DBAs”,
“architectural DBAs”, and “full service DBAs”, with a prediction that the entry
level requirements for “operational DBAs” would drop over time to the training
level required of mainframe operators while the wide ranging requirements for
the latter two would rise. (The distinction between the latter two is that an
architectural DBA might not be able to train an operational DBA or quickly
execute database operations herself(#WIT).
Back in the day of designing data models and modular programs together, the
coders didn’t start programming until at least the eventual smooth flow of data
through the system was planned. In 1978 Yourdon and Constantine published the
first edition of Structured Design. In 1981 Greg Lupfer tossed it on my desk
and said something like “I do this. You’re obviously trying to bring all our
code up to this standard and this will help you describe what you’re thinking.”
It dovetails perfectly with Codd.
Operational DBAs will never go away, but probably the continuing efforts to
automate the annoying and repetitive bits will continue pushing that role from
intellectual toward training. (This is not the first time [or even the
second!] Larry has announced the new release to be a self-running database
creating no future need for DBAs, but they are getting better and better at
some important bits.)
Folks who have the desire and capacity to do more would do well to grab a copy
of Structured Design (any edition, really). Do be advised that it creates a bit
of “Waterfall Design” versus “Agile Design” cognitive dissonance, and that
rarely do you get to do a full design any more before implementation begins.
Adding an understanding of dataflow diagrams to your thinking, however, will
help you avoid building box canyons where the next phase has to discard 80% or
more and facilitates your ability to play in the world of #DEVOPS.
And understanding data flow certainly helps figure out what and where in a
system you want to snag things (in addition to the database) to back up for
possible recovery and replay.
Sigh. Sorry so long… DBAs will survive the announcement of their deaths longer
than COBOL.
mwf
“operational DBA” is probably about the same as MLADEN calls production DBA.
Have you ever had to undo a broken MS patch? Or even a phone patch? yeah,
they’ll never ever make a mistake again, because they’ll test it on all the
data and systems in the world and do a full regression test for everyone before
they release anything, right? Sheesh. Sell that one to a CFO.
From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mladen Gogala
Sent: Wednesday, October 04, 2017 6:39 AM
To: oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: Future of Oracle DBA - Man vs Machine
Hi Amit,
Oracle DBA has never been just a DBA, the role was always one of the general
technology expert. As a DBA, I was writing scripts to load/unload the data,
creating my own monitoring tool, writing custom reports for business, tuning OS
parameters and rewriting queries for developers. With increased specialization
and programmers who sometimes don't understand the architecture of the system
they are working on, IT departments do need a SME who knows the DB and OS
architecture and can help developers when they inevitably run into problems.
What has been affected is the role of a production DBA, who monitors the
database and reacts to events. That has been largely delegated to OEM and
similar products. There is no longer a need for a dedicated person to be a
"production DBA".
Automatic upgrades are bad a joke, just as Stefan has said.
Regards
On 10/04/2017 01:07 AM, AMIT VERMA 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@xxxxxxxxx<mailto:v.amit84@xxxxxxxxx>
"Winning takes talent but it takes character to keep winning"
--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
<html xmlns="http://www.w3.org/1999/xhtml";>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br>This message is intended only for the individual named. It may contain
confidential or privileged information. If you are not the named addressee you
should in particular not disseminate, distribute, modify or copy this e-mail.
Please notify the sender immediately by e-mail, if you have received this
message by mistake and delete it from your system.</br>
<br>E-mail transmission may not be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
processing of incoming e-mails cannot be guaranteed. All liability of the
Vontobel Group and its affiliates for any damages resulting from e-mail use is
excluded. You are advised that urgent and time sensitive messages should not be
sent by e-mail and if verification is required please request a printed
version.<br/>
</p>
</body>
</html>
