DBAs and Dinosaurs

by Jul 8, 2014

You have to admit that title is catchier than yet another “Death of the DBA” blog.  And that was exactly the direction I was headed until I ran a quick search to find a reference that not only exposed actual predictions of the death of the DBA as a profession but also blogs debunking those same predictions.

First Mammal

The DBA as defined in the 1990s is certainly headed for extinction if not already fossilized among the raised floor datacenters of the past.   But those DBAs bear little resemblance to the nimble, scurrying creatures forced to adapt in recent years to massive increases in numbers of instances, databases, and size of databases that I have witnessed as a database tools product manager.    Certainly there have been lamentations at the loss of complete control these creatures once enjoyed; first of storage for those who remember when a DBA could specify which device would contain which bit of data to reduce contention; then to the virtualization trend where databases were the last components of the application stack to fall; and now many wring their hands in fear of the inevitable pull of the cloud.

But I have heard too many tales of impending doom for the DBA role that never transpired to take such predictions seriously anymore.  I took the first such prediction I heard seriously because it came from a smart and successful entrepreneur, warning our database tool vendor executives that our target user was headed for oblivion due to advancements in the database engines themselves.   This prediction failed to transpire, much like the many predictions of coming apocalypse we have heard through the years.  And my skepticism at the predictions increased exponentially with each new wave of impending change.

  1. The first wave of predictions came from the database vendors themselves, touting the self-managing and self-tuning capabilities of new database releases.   (I recall some particularly bold claims from a Microsoft engineer hyping the launch of the new SQL Server 7.0 release.) But they failed to take into account the growing complexity they were introducing in database features that outstripped the advancements in automating mundane tasks and self-tuning engines that worked “most of the time” but sometimes failed miserably.
  2. After that came the distribution of roles and responsibilities once reserved for the DBA.   DBAs lamented performance issues directly caused by the ignorance of storage administrators believing SANs were independent of the arcane DBA practices of meticulous manual storage management to reduce I/O contention.  (The database vendors later led the way with database-intelligent storage optimization.)  Although storage never went back to control by the DBA, the influence of DBAs helped to restore some level of sanity to the faulty ideas that mission critical database transaction storage could be treated no differently than file storage without consequence.
  3. Still later the virtualization wave finally hit the database, with Microsoft SQL Server embracing the concept before any other major vendor as a differentiator.  I know many virtualization advocates among extremely experienced DBAs, but all preached the caveat that the DBA should control the virtual environments where databases were running.    I heard several cautionary tales of database performance hits that were traced back to ignorant system administrators moving heavy application images onto database servers without notification of any DBA.  The DBAs in question proved their worth by being the ones to anticipate the problem, isolate the problem, and use the situation to justify regaining at least some say about what virtual images could share resources with critical databases and their applications.
  4. The latest predictions of gloom for the DBA professions concern the movement of more data to the nebulous “cloud”, with the presumption that this data will now be managed perfectly in the cloud without risk or performance impact.  (Never mind that this management will inevitably fall back on the ever-evolving DBA role.)

That leads to my conclusion that the DBA is more like that scurrying insectivore in the picture, surviving and adapting; than the giant over-specialized and antiquated creature in my title.  Data is more important than ever to business success.   Data is the key asset to many modern businesses and when the management and mining of that data for business intelligence is your business’ core competency, you cannot afford to totally outsource oversight and control of that key asset to a faceless vendor.  The data itself may be most efficiently housed in a cloud environment, but someone with the sensibilities of a DBA for data integrity, redundancy, security, and performance will always need to be managing it, at least for the wise business managers.

More on the factors that cause business managers to conclude they don’t need a dedicated DBA (until something goes wrong) next time.   Accidental, reluctant, or any of the other terms that have been coined to designate these brave people filling the role of a DBA without prior training is not a new phenomenon, but it is increasing.