RE: Future of Oracle DBA - Man vs Machine
Date: Wed, 4 Oct 2017 13:38:01 +0000
Message-ID: <11291_1507124293_59D4E445_11291_15248_1_ECDEF0CC6716EC4596FCBC871F48292AB1903577_at_ZRH-S231>
„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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham
Sent: Mittwoch, 4. Oktober 2017 15:09
To: gogala.mladen_at_gmail.com; oracle-l_at_freelists.org
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_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala Sent: Wednesday, October 04, 2017 6:39 AM To: oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org> 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
- What will be future of Oracle DBA roles for the new learner & existing DBAs?
- 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"
--
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>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Oct 04 2017 - 15:38:01 CEST