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… If you want a partner to give you senior DBA support for a fraction of the cost in our Expert on Demand Service. Check that out if you want, or read on and bring the right team together on your own. Either way works, just take care of your data!
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
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?
You hire for the right skills. Troubleshooting skills. Calm under pressure. You find folks who care about data.
Another way? Reach out to us at Straight Path Solutions. We offer a few options to help out. One of our favorite ways? What we call Senior SQL Server Expert on Demand – buy a small bucket of hours each quarter. We review your environment, we are there for questions and challenges, We help you grow your team. We keep your environment up and we’re there for you if anything bad happens, but we try and keep that from happening with you. Check out our Expert on Demand service.
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?