Why Hire A SQL Server DBA?

Why Hire A SQL Server DBA?

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 or a SQL Server DBA services company?

I’m glad you asked; I can think of a few reasons… Whether you hire a DBA, train up a DBA from your existing team, or partner with a firm like Straight Path or one of the other great firms out there, the point is – you need to 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

Absolute Data Destruction
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 don’t like being woken up after hours. Either way, we will 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, and 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 first to understand why a best practice exists and then implement those 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 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 it.

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 not to let the database be the cause for the 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, you are likely 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 I might be eating into some billable time here because I do some consulting on the side, but that’s fine. I have a busy life with 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 fewer 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 will take longer. It 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. The system is belly up; drives are burned, whatever. How quickly do you want to be up? Your director, VP or CIO wanted 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 mothballs 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; likely, 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. Maybe our remote managed SQL Server DBA services are what you need for now?

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?

Subscribe for Updates


15 thoughts on “Why Hire A SQL Server DBA?”

  1. 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.

  2. Pingback: Vendoran
  3. Pingback: Ted Krueger
  4. Pingback: 刘江/LIU Jiang
  5. Pingback: 咻~咻~我是风
  6. 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. 🙁

  7. For those whom are stating DBAs are useless, make sure you do not ask the DBA for help when something breaks that Google cannot solve. Goodluck.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share This