There are many reasons why DBAs are not on the fast path to extinction. 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 DB2 Control Center. But many organizations prefer to use heterogeneous solutions that can administer databases from multiple vendors all from a single console. Most of these tools have had self-managing features for years.

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. 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. 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 should become a thing of the past. Instead, the modern DBA will need to understand multiple DBMS products, not just one. 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.