Who Is Responsible for SQL Server?
Tell me what you think about this conversation. I must first clarify something about the conversation, though. It’s not an actual conversation I’ve had with a specific person or one prospective client. It’s not verbatim. Rather, it’s an amalgamation of many conversations I’ve had over the years. It starts when I ask who is responsible for SQL Server in their environment.
By this point in the conversation, they’ve usually told me about a performance problem they’re struggling with. Or maybe an availability issue that’s been plaguing them. They’ve shared what they’ve done to try to remedy the situation. For example, maybe they’ve increased hardware resources, or shuffled some scheduled jobs around, trying to make things better. It hasn’t worked.
Note: I’m definitely not judging their attempts. Not in the least. If someone asked me to diagnose and solve a Linux DNS issue or debug some C# code, well, let’s just say they’d never ask me again. And things would be a lot worse after my attempt. So, I applaud their effort to fix an issue that is outside their area of expertise. Necessity is the mother of invention, or at least it’s the mother of Googling for help.
The rest of the conversation
Anyway, as the conversation continues, it goes something like this:
Me: “Ok, so who is responsible for SQL Server in your environment?”
Them: “Well, we are.”
Me: “Ok, good. Frequently we find that if a company doesn’t have a DBA on staff, either an experienced application developer or perhaps a systems administrator is the one tasked with taking care of the SQL Servers in their spare time. Do you have someone like that?”
Them: “Well…”
Me: (waiting)
Them: “Ok. So, the infrastructure team believes that SQL Server is an application. It’s loaded on top of the O/S, on top of the hypervisor, the network, the storage, etc. So, they don’t want to own it.”
Me: “Ok, I get that. SQL Server is not exactly infrastructure. So, is the App team responsible for it?”
Them: “Well. The developers say that should it live with the infrastructure group. They say ‘It’s in the name – SQL Server. Servers are part of infrastructure.’ So, no they don’t really want to be responsible for it either.”
Me: “Ok, got it. So, who keeps it healthy? Who takes care of it when something goes wrong?”
Them: “That’s why we’re talking with you.”
Where should SQL Server live?
For companies with a DBA team, the answer is easy. SQL Server lives with them. They own it. They are responsible for keeping it reliable. For keeping it secure. And for keeping it performing well.
But what about for companies that do not have a team of DBAs? Who should be responsible for them?
We’ve seen SQL live with infrastructure, where it’s treated as infrastructure. We’ve also seen it live with application developers or with the BI team. In some companies it’s the CIO who manages the SQL Server environment.
And these were not small companies. These are companies with more than $100M in annual revenue, with hundreds or even thousands of employees. Yet they didn’t need a full time DBA. They had 10, or 20, or maybe 50 SQL Server instances. They don’t have enough DBA work to justify hiring a DBA, much less a couple of DBAs. Because two is one and one is none.
And yes, that’s where we can help.
I’m curious, though. If you do not have a DBA, who is responsible for SQL Servers in your company? Who’s telephone rings when it’s slow? Who’s making sure the backups are running?
Want to know more?
Here are other posts that you may find helpful if you don’t have a DBA on staff.
- Working Without A SQL Server DBA? Do These 10 Things Now
- 4 Ways to Better Manage SQL Server Without a DBA
- Who’s Caring for Your SQL Servers?
- 10 Unseen Things Successful DBAs Do
- Why is it important to monitor SQL Server?
- Do I Still Need a SQL Server Health Check?
- The SERO Script Library
Or, if you’d like to learn a bit more about how we help companies with our a SEROShield – DBA as a Service, feel free to reach out.