Death of the DBA - from an Oracle perspective

In relation to an article from John’s blog, I posted the following and thought it may be worth widening the audience to see what other views are out there.

The “death of the DBA role” has been prophesized for many years now, in fact Oracle 9i was pumped as the “shrink wrapped DB solution” to allow non-techs run databases and we all know how well that worked out for organisations who tried to go it alone with inexperienced tech people.

The main thing I’ve noticed on my adventures with Oracle [7.1 onwards] is that the more that people believe the sales hype and try to simplify these processes, the more technical the solution underneath needs to be – “all things to all people” is a hard trick to pull off.  If all applications were generic running on a vanilla patch level with predictable IO requirements along with consistent requirements, then SaaS/DaaS is an ideal solution SO long as, all security requirements and performance spikes are handled within the vanilla options and limits these offerings are limited by.

Move to a more “organic” flow of larger enterprise requirements and suddenly the SaaS/DaaS becomes slightly less of an obvious choice and then mix in the licencing costs and reusability of licences [Dev v Test v Perf v UAT v OAT v Prod V DR] and suddenly the choice isn’t so clear cut. If you then look at environments held to higher security standards [think government or fintech/trading, etc] and escalated costs of the models above, then you are back at the “horses for courses” point.

Oracle’s strength/weakness is that it provides to a wide range of requirements above a certain price point for its Enterprise solution. Under that price point [or near it] then other solutions start to bear fruit esp when functionality costs [partitioning, encryption, etc.] are explained to business owners. Solutions such as SQL Server, MySQL, Hadoop, MongoDB, MariaDB, NoSQL, etc all suddenly start fitting niches that the larger Enterprise solution is too expensive for. Once you compare these to Oracle Standard Edition then suddenly the cost factors are closer so you start looking at the other costs associated with DB ownership –resilience, reliability but primarily SUPPORT. If your first line of support is google/forum/occasionally manned ticket desks/etc then suddenly your cost saving on licencing needs to seriously be weighed up for the cost of outage duration that may be involved when there is no P1 support available 24/7.

Understanding your risk profile to gauge against your ownership costs is crucial; being able to call out these costs and risks requires a deep technical experience along with business awareness which is where a good DBA will save a company money [and probably reputation] in the long run.

I’m not saying Oracle doesn’t have its fault and I’m in no way a fanbois – I’ve experience in a wide range of industries and small to large companies where Oracle hasn’t been the DB of choice for a variety of reasons – but it is the market leader for a reason. Oracle’s product choices offered along with the varying support tiers available make it a smart choice for Enterprise class service – I avoid using the term “large database” as that can be exceedingly misleading as I remember 50Gb being considered a large database and now 200Tb considered a reasonable sized data warehouse. The main thing is that over the last 20+ years, every time a major player in software has dominated a market, it left niche players room to get established and grow, forcing the majors to either up their game or fall by the wayside. In all of this, technical people were needed and whilst demand hit peaks and troughs, data management was always needed and as such, the DBA role was always required.

In the 1990’s the DBA role was mainly command line driven with crontab type entries used to schedule routine tasks. Roll forward 20+ years and even before Cloud, the DBA role requires the candidate to understand application layer interactions as well as web tier implications for data security, role based access and how this all can be driven through a GUI as well as command line. Now a DBA is required to understand how the gui works and its technical requirements along with how the database they manage hangs together.

In summation, I think that whilst more generic interfaces and generic task management will be prevalent, the ability for a DBA to involve themselves at the technical ground level and deal with the unexpected results from rapidly changing software, will leave any organisation deploying enterprise class solutions with a mandatory requirement for appropriately skilled DBAs. If only from a risk mitigation side of the equation, having the ability to know when a vendor is pulling the wool over your eyes will still be as critical in 20 years as it was 20 years ago.

Cheers

Martin