Why should you do it by hand if you can automate DBA processes? Anything you
can do probably can be done better by the computer – if it is programmed to do
it properly. And once it is automated you save yourself valuable time. And that
time can be spent tackling other problems, learning about new features and
functionality, or training others.
Furthermore,
don’t reinvent the wheel. Someone, somewhere, at some time many
have already solved the problem you currently are attempting to solve. Look to
the web for sites that allow you to download and share scripts. Or if you have
budget money look to purchase DBA tools from ISVs. There are a lot of good tools
out there, available from multiple vendors, that can greatly simplify the task
of database administration. Automating performance management, change
management, backup and recovery, and other tasks can help to reduce the amount
of time, effort, and human error involved in managing database systems.
Of course, you can take the automation idea too far. There has been a lot of
talk and vendor hype lately about self-managing database systems. For years now, pundits and polls have been asking when automation will make the DBA job
obsolete. The correct answer is "never" - or, at least, not any time soon.
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. Yes, little-by-little and step-by-step, database
maintenance and performance management is being improved, simplified, and
automated. But you know what? DBAs will not be automated out of existence in my
lifetime – and probably not in your children’s lifetime either.
Many of the self-managing features require using the built-in tools from the
DBMS vendor, but many
organizations prefer to use heterogeneous solutions that can administer
databases from multiple vendors (Oracle, DB2, SQL Server, MySQL, etc.) all from a
single console. Most of these tools have had self-managing features for years
and yet they did not make the DBA obsolete.
And let’s face it, a lot of the DBMS vendors claims are more hyperbole than
fact. Some self-managing features are announced years before they will become
generally available in the DBMS. All vendors claims to the contrary, no
database today is truly 100% self-contained. Every database needs some amount
of DBA management – even when today’s best self-management features are being
used.
What about the future? Well, things will get better – and probably more
costly. You don’t think the DBMS vendors are building this self-management
technology for free, do you? But let’s remove cost from the equation for a
moment. What can a self-managing database actually manage?
Most performance management solutions allow you to set performance
thresholds. A threshold allows you to set up a trigger that says something like
“When x% of a table’s pages contain chained rows or fragmentation, schedule a
reorganization.” But these thresholds are only as good as the variables you set
and the actions you define to be taken upon tripping the threshold. Some
software is bordering on 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
such 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 the DBA trusts the software, he 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.
Of course, not all DBA duties can be self-managed by software. Most
self-management claims are made for performance management, but what about
change management? The DBMS cannot somehow read the mind of its user and add a
new column or index, or change a data type or length. This non-trivial activity
requires a skilled DBA to analyze the database structures, develop the
modifications, and deploy the proper scripts or tools to implement the change.
Of course, software can help simplify the process, but software cannot replace
the DBA.
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.
Because each company is different, the DBMS must be customized using
configuration parameters. Of course, you can opt to use the DBMS “as is,” right
out-of-the-box. But a knowledgeable DBA can configure the DBMS so that it runs
appropriately for their organization. Problem diagnosis is another tricky
subject. Not every problem is readily solvable by developers using just the
Messages and Codes manual and a help desk. What happens with particularly
thorny problems if the DBA is not around to help?
Of course, the pure, heads-down systems DBA may (no, let's say 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 (
more
details here). 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.
Finally, keep in mind that we didn't automate people out of existence when
we automated HR or finance. Finance and HR professionals are doing their jobs
more efficiently and effectively, and they have the ability to deliver a better
product in their field. That's the goal of automation. So, as we automate
portions of the DBA’s job, we'll have more efficient data professionals
managing data more proficiently.
This blog entry started out as a call to automate, but I guess it kinda
veered off into an extended dialogue on what can, and cannot, be accomplished
with automation. I guess the bottom line is this... Automation is key to successful, smooth-running databases and applications... but don't get too carried away by the concept.
I hope you found the ideas here to be useful...
and feel free to add your own thoughts and comments below!
