Why on earth would anyone hire a Database Administrator? Your Windows Admin can install SQL Server with just a few clicks – It only takes a few more clicks to put a database there and grant permissions. Most of your vendors have simple setup scripts including database deploys… Why spend all that money on a SQL Server DBA salary?
I’m glad you asked, I can think of a few reasons…
DBAs Are Mean Care About Your Data
Your developers hopefully care about the data. Your vendors care about their bottom line might even care about your
I'm sure they are great at their intended process but do you hire your developers from them? You might need a DBA 
data as well. Your system administrators like things to run smoothly also; no one likes a failure. Your database administrators, however, have a vested interest in keeping your data clean and healthy. A good DBA will say “no” quite often (or, more accurately, “not yet”; “not deployed like that” or “no until security is cleaned up”) if something is being done without concern for security or performance best practices in mind.
Sure we can come across as tough sometimes but when you stop and ask why, it is usually because we care about the data. Maybe it’s not so altruistic and we just don’t like being woken up after hours. Either way, we are going to do all we can to fight silliness at every stage of a database’s life.
Sometimes it is appreciated and understood. A development manager at one point in my career sent me a note around review time that included this statement, “Our developers are very appreciative that, while you can be one tough and principled SOB, you are usually right in the end!!” That isn’t to gloat, it’s to say that a DBA who cares to do the job right and wants things right the first time can make a difference in the long run.
So Reason 1: A DBA cares about the database. It’s a myopic concern. Yes we care about the other facets of an application but it all stems from our desire to make the databases be all they can be. The other roles? They have their primary focus on something else (as they should!)
DBAs Like Best Practices
I’m talking about experienced and effective DBAs here. What I mean by the heading is that a database administrator knows what is beneath the set-it-and-forget-it installation options and deployment steps. We read books like Professional SQL Server 2008: Internals And Troubleshooting (some of us even read them on personal time!). We study up on the database engine we support. We want to first understand why a best practice exists and then implement the ones that make sense for our organization. We aren’t going to accept defaults, we aren’t going to ignore empirical evidence and try the first thing that a search engine shows us in production (hopefully). We may not just accept a hand me down server for that huge production ERP deployment. We might discuss SAN optimization with the storage team. When we look at a backup solution for the enterprise we will ask questions that are relevant to SQL Server and the recovery needs we support. We won’t let a vendor do something dumb without a lot of whining and attempts to correct.
Reason 2: A DBA cares to do the right job the first time. Again, you can even let it boil down to the self serving desire to not let the database be the cause for blame of a production outage. I don’t care, I’m still going to make sure that the database environment I support is running as well as it should and that we aren’t sacrificing best practices and performance (at least not always!) for the sake of “We’ll fix it later…”
DBAs Can Make Users Happy
How well are your systems running? Performance complaints? Do you have a DBA? If you don’t and the systems have a database back end it is incredibly likely that you are suffering from a lack of database TLC. I don’t know how many times I have been asked to consult on an engagement to “just make it faster!” or inherited horrible performing environments that were easily fixed with DBA 101 stuff (updating statistics, rebuilding indexes, the right settings, etc.). I know that because I do some consulting on the side, I might be eating into some billable time here but that’s fine, I have a busy life with the family, church and full time work. As a DBA, I usually know where to start looking for database performance problems. As a DBA, I usually know what planned maintenance to do on the database server and databases to keep things running smoothly. If you had a DBA, you would have less performance related fires; you wouldn’t have to pay an invoice to a consultant to come in and save the day. Your Sys Admin could help figure out an issue but, if they don’t have a lot of hands on – and academic – knowledge of database performance tuning and troubleshooting, it is going to take longer and could potentially include painful results if guesses/blind stabs are made. They specialize in a different skill set.
Reason 3: Database Administrators can prevent (or more easily resolve) performance issues or troubleshooting situations.
Oh No!!! Everything is down!
Picture a disaster scenario. System is belly up, drives are burned, whatever. How quickly do you want to be up? Your director, VP or CIO wants it yesterday and they want to know why your people are running around in panic mode looking stuff up on search engines.
A good Database Administrator (again, hopefully) is practicing restores or devising clever ways to sample for restore failure possibilities. They are thinking about disaster scenarios and possible responses to them. They have done restores before and have likely dealt with strange errors, corruption or common failure scenarios. Hopefully they are familiar with forums and know where to help find (and test) information. They can think on their feet about the ramifications of various recovery options or settings changes in a time of crisis.
Reason 4: Even if you stuffed your DBA in a closet on moth balls and only opened the door when danger strikes the time saved in that disaster and the possible data saved during that disaster justifies a DBA role in a lot of companies.
Your Data Is Your Business
How much do you rely on your data? Analysis of trends. Sales Forecasts. Payroll data. Sales data. Customer lists. Partner lists. Inventory. Shipping and Tracking information. You name the piece of your business, it is highly likely that you can’t name 2 or 3 that don’t have data stored in a database. What happens if you lose that? What happens if you can’t get to it fast enough? What happens if you can’t trust it to be accurate?
Reason 5: Your data is pretty important. You might have hired a Microsoft Exchange experienced system administrator because you realize how important e-mail is to your company. How useful is that e-mail system without your core systems described above? How much does your organization spend on various forms of insurance?
How Can I Get a DBA?
I could go on with more reasons. I could give you horror stories. I could tell you about the strange things vendors have requested (and the responses I’ve gotten when questioning those requests… Things like “look.. no one ever complained about that before”). I could go out and find statistics that talk about companies closing their doors because of data loss. I think you get the point though.
If you have database instances and applications running, the simple truth is that you probably have enough work to keep a DBA busy. Maybe you could start smaller and get someone on retainer. I do that with some companies as an advisor/mentor. There are plenty of other people offering the same types of services, some larger companies dedicated to providing remote DBA or DBA Advisory services. Maybe you can hire someone with a good DBA background who has other interests and could wear a second hat for you.
I would say that in the New England job market, this must be a known fact – It seems like database roles are always being advertised or actively recruited, even in the down economy. So I would say get your DBA search on and fill that role already! Do it quick before the most experienced DBAs are gobbled up.
I think it’s clear what I think – You Need To Hire a SQL Server DBA (Be that a full time person or at least a consultant to come in and help ensure things are running well)
What do you think? Why do you (or don’t you) have a DBA? Any horror stories from when you’ve been burned by not having that role filled?
Nice post Mike. It’s totally true. There’s too many database servers out there that haven’t been touched since the setup wizard finished.
Many years ago I worked for a software vendor supplying a SQL Server based system. As I recall none of the clients had a DBA. Some of these were £50M/year outfits and data drove everything. While it was a client responsibility to check backups I used to if I had access. This was before common use of ADSL so not always easy. I could probably count on one hand the clients that actually had a handle on backups.
I visited the site of one client who wouldn’t give us remote access for “security” reasons only to find their backups had not been running for close to a year. Luckily any disaster was averted and they quickly realized what this over sight could have done to their business.
Rhys -
Great point. I cut my teeth working in support at a software vendor. That is how I got my interest in databases and SQL Server in particular. Because of my interest and full force dive into the database world, I became the go to guy for database related issues there. Man, the horror stories that came out of that environment. I linked to my post about questions to ask vendors above but I actually should blog about advice vendors can give to clients to be more proactive. In fact I think I will… I jokingly paint the vendors with a bad brush but companies handling vitally important data without DBAs need to take some responsibility also.
You must be a DBA
How did you guess?
I have also seen where companies promote techs to the DBA role but don’t provide adequate training and end up with risky and sometimes failed systems. One such instance is where this Fortune 1000 client had their Financial systems in FULL Recovery because they knew they wanted point in time restores, but they never backed up the transaction logs. The maintenance plans were directed to shrink the database instead. Another instance is where the maintenance plan would fail on SQL 2005 because they didn’t have the SP2 fix on the paths for the maintenance plans.
It is hard to quantify how much a DBA saves you on your bottom line until you have had some disaster. I always tell my clients to figure up how much it would cost them if they were down for a day, or even 4 hours.
Cherie – apologies for the late response. You raise some great points. I can’t tell you how many times I’ve seen DBs in Full Recovery mode with no log backups happening and shrink jobs were created. Probably the biggest common mistake out there. But that is what happens when you don’t hire a well trained SQL Server DBA and ask an already busy, overburdened, SQL epxerpience lacking, “jack-of-all-trades” team to manage your enterprise databases. Watch out.