Automation and autonomics are at the forefront of database and system administration and management these days. And that is a good thing because automation and autonomics can minimize the amount of time, error and human effort involved in assuring and maintaining efficient database systems and applications.
And, yes, there is also a lot of vendor hype about self-managing database systems, from the DBMS vendors themselves, and from ISVs selling performance and maintenance solutions and tools. So I suppose it stands to reason that folks will start to ask questions like this: If the DBMS and databases are going to manage themselves, will anyone need a DBA?
But don’t get too excited about the extinction of the DBA! There are many reasons why DBAs are not going anywhere anytime soon. Self-managing databases systems are indeed a laudable goal, but we are very far away from a “lights-out” DBMS environment. Many of the self-managing features require using the built-in tools from the DBMS vendor, such as Oracle Enterprise Manager or IBM Data Studio. But many organizations prefer to use heterogeneous solutions that can administer databases from multiple vendors all from a single console. And many of these tools have had self-managing features for years. And we still need DBAs…
Most performance management solutions allow you to set performance thresholds. But these thresholds are only as good as the variables you set and the actions you define to be taken when the threshold is tripped. Some software is intelligent; that is, it “knows” what to do and when to do it. Furthermore, it may be able to learn from past actions and results. The more intelligence that can be built into a self-managing system, the better the results typically will be. This brings us to autonomics… but what is autonomic computing?
Autonomics is more than mere automation… Autonomic computing refers to the self-managing characteristics of distributed computing resources, adapting to unpredictable changes while hiding intrinsic complexity to operators and users. And yes, the more our systems can manage themselves, the better things should become.
But who among us currently trusts software to work like a grizzled veteran DBA? The management software should be configurable so that it alerts the DBA as to what action it wants to take. The DBA can review the action and give a “thumbs up” or “thumbs down” before the corrective measure is applied. In this way, the software can earn the DBA’s respect and trust. When DBAs trust the software, they can turn it on so that it self-manages “on the fly” without DBA intervention. But today, in most cases, a DBA is required to set up the thresholds, as well as to ensure their on-going viability.
Furthermore, database backup and recovery will need to be guided by the trained eye of a DBA. Perhaps the DBMS can become savvy enough to schedule a backup when a system process occurs that requires it. Maybe the DBMS of the future will automatically schedule a backup when enough data changes. But sometimes backups are made for other reasons: to propagate changes from one system to another, to build test beds, as part of program testing, and so on. A skilled professional is needed to build the proper backup scripts, run them appropriately, and test the backup files for accuracy.
And what about recovery? How can a damaged database know it needs to be recovered? Because the database is damaged any self-managed recovery it might attempt is automatically rendered suspect. I mean, if the database was all that smart to begin with why is it damaged and in need of recovery, right? Here again, we need the wisdom and knowledge of the DBA.
And there are many other DBA duties that cannot be completely automated. Of course, the pure, heads-down systems DBA may eventually become a thing of the past. Instead, the modern DBA will need to understand multiple DBMS products, not just one. And that includes non-relational big data solutions like Hadoop and NoSQL database systems.
DBAs furthermore must have knowledge of the business impact of each database under their care (for more details see Business Eye for the DBA Guy). And DBAs will need better knowledge of logical database design and data modeling — because it will advance their understanding of the meaning of the data in their databases.
So, no, we won’t automate the DBA out of existence. It can’t be done… but we can make the job of DBA more interesting and useful, as we remove much of the mundane and repetitive components through automation and autonomics.