Why should you hire a DBA? What value do they bring to your organization? I heard this recently from a director who was re-evaluating his staffing, probably to look at reductions. I discussed it with a friend who's a manager (and former DBA) and his response was “Why not?”. Two sides of the coin, but something that got me thinking. Most people that manage databases know that they bring value to their company and they work hard for their money. While most DBAs are paid well, at least in my experience, most managers, directors, and upper management aren't always aware of the value that a database administrator brings to the organization.
I decided to look at this from two perspectives, the production DBA and the development DBA. Both of these are different and distinct jobs, and while both are sometimes handled by the same person, they have different values to the organization. This article will look at the production DBA and a future one will examine things from the perspective of the development manager.
What Does He Do All Day?
A production DBA has a number of responsibilities, most of which you never know he or she has accomplished or is doing every day if they're doing a good job. I know that my primary focus in starting a new DBA job, something I've done 4 times in the last ten years, I work to make myself “insurance”, the guy you need to call if something is horribly wrong as quickly as possible. The rest of the time, my environment is usually very stable and it doesn't appear that I am needed on a day to day basis. So what do I do?
As a production DBA, I have two main responsibilities that I have to ensure are covered: restores and availability. That sounds a little funny and many of you will be asking yourselves why these two items, or at least, why restores? What about backups? What about performance tuning? I'll get to those, but let me explain what these are and why they are important.
Backups aren't important. A strong statement, but any individual backup, and the vast majority of them in the real world, are not important. No one cares about backups, other than the DBA. But restores, however, are very important. They are so important that if you can't do a restore, then you might want to keep your resume or CV in a handy place and up to date. Most people that are non technical, care very deeply about restores occurring when they need to occur. So as a DBA, since we do not know when a restore will be needed, we care very deeply about ensuring backups are occurring and are accurate. We also care about restores, specifically our ability to do them on demand. Which is a DBA will practice restores periodically on the same server, different servers, new databases, etc. Many times the individual footing the salary for the DBA doesn't see this, but they are usually occurring. And they can be critical to your business.
Equally important as restores is availability. If your data is not available, if you cannot connect to the server, if your people cannot run queries, that's a problem. A much bigger problem than if the server is performing poorly. I know some VPs might disagree, but slow performance is much better than no performance. So ensuring that the database is available is another primary job for the DBA.
Now SQL Server pretty much runs itself. That I'll agree with most people, so the day to day value of the DBA might appear to be diminished, but that's not really the case. As many companies that have called me to consult have learned. There are a great many things involved with ensuring availability, some of which actually lower your uptime, but are still necessary. Many SQL Server DBAs are abreast of the current service packs and hot fixes that are available for SQL Server. More often lately than other database platforms, SQL Server does need some of these patches to ensure availability. During the SQL Slammer weekend, most of my servers continued to run while many servers not managed by DBAs, mostly in the development areas of my former company, were infected and brought down the network. In a company of 12,000 people, having the network down for a couple days is a big deal. And it was something that might have been prevented had a few more DBAs been hired to handle patching and control of all servers.
A DBA also needs to control the environment. DBAs are often accused of being bottlenecks, of stifling change or making it difficult to move forward in the evolution of the system, all of which is very true. But these actions bring value to the company. Most stifling activities are not because the DBA is lazy or wants the power (though this may sometimes occur), it's because there is a need to review the changes and ensure that they do not negatively impact the environment, whether that is performance related or availability related. A person that edits a stored procedure online is more likely to cause a disruption than one that controls the change, ensures it is tested, and implements a methodology to ensure the tested code moves into production THE SAME WAY it moved to the test system. In many cases where a non-DBA was allowed to implement change that I have been involved with, there are more often than not issues, and very often there were issues that were fixed on the fly. This type of methodology, if you can even call it that, will cause more and more issues over time. Even having an issue 1 out of 10 times isn't acceptable at the data level.
This control also ensures that data integrity, that the data in the database actually means what you want it to mean, or what it should mean, is enforced. While DBAs often say “garbage in, garbage out” in referencing the data and not wanting to be responsible for changes made by every data entry person, they still take pride and responsibility for the data. From the low level tasks of ensuring that constraints exist, triggers are functioning, from the periodic monitoring for corruption in the database to the high level tasks of actually “fixing” data that someone has broken. Myself and friends have fixed hundreds of broken data rows when someone presented us with a frantic “whoops, I just deleted a row” or a “I accidentally changed a thousand prices” type of phone call. And more often than not, a manager, director, or other senior person isn't informed that something was fixed. Having a DBA on staff ensures that your changes and enhancements are in line with ensuring that your data is intact, available, and recoverable.
After that, a DBA needs to find time to performance tune, one of the next big areas. Examining frequently run queries, checking on indexing strategies, and lots of testing, testing, testing. A DBA doesn't want to put things into production without being sure they will help, so testing new indexes and query structures is a good part of their routine. A DBA also will be looking for handling the basics of administration, rebuilding indexes, monitoring space, ensuring that many of the little things that can cause issues over time are tracked and handled before they become issues.
More often than not, the daily work of the production DBA isn't visible to those that pay his or her salary. A DBA may indeed appear to be insurance, someone that doesn't earn their money until an issue arises, but this isn't usually the case. Good DBAs are hard to find, but most DBAs will bring you values that you need, but might not see initially. Even if they struggle to ensure these basics are accomplished, they are truly valuable to your company. A DBA that accomplishes these goals and has time to performance tune and work with development, etc., is someone not easily replaced and a DBA you certainly want to hold onto.
Tim O'Reilly wrote last year "We're entering a new world in which data may be more important than software." If that's truly the case, then having a DBA brings great deal of value that any organization cannot do without.
I know I haven't delved deeply into the practicalities of what a DBA does. I may get to that in the future, but if any of you have the urge to share some knowledge on how you go about these duties and responsibilities, please visit our Writer's page and jot some notes down in a text file.
