Do This Before You Contact Your SQL Server Consultant |

Do This Before You Contact Your SQL Server Consultant – SQL, Code, Coffee, Etc.

Say you need outside help. You’ve exhausted all the things that you could do and, still, nothing works. So, you decide that calling in for help is the next sensible thing to do. Let’s say this is the first time you’re asking for somebody’s help. You decide which consultant to work with. The hardest part, if you’re doing this for the first time, is how to start that conversation.

The first conversation is the most critical one. Obviously, you cannot just turn over your SQL Server instance and wait for the bill. Some prep changes what you get out of that first conversation. It means spending less time covering the basics and more time focusing on the problem that made you pick up the phone in the first place.

Here’s what’s worth having ready before you make the call.

(And, not incidentally, if you are a new SQL Server DBA hire, you can use the following to get a baseline understanding of the environment you’re now facing.)

Determine what’s wrong with your server

Here’s the thing. Your consultant is a highly technical person, but you don’t always have to speak in technical terms. Explain the pain points from the users’ perspective. Is the UI slow? Are users experiencing timeout issues? Is a button not responding in a timely manner? Look at the problem through the users’ eyes and understand their pain.

An important thing to take note of is what feels slow or broken. Is it specific like a report? A batch job that has been failing to meet the SLA? Is it the whole application? Ingestion pipeline failing to finish at all?

Another important thing to take note of is the timeline. When did this start happening? Is it after a vendor update? Is it after releasing a new ingestion tool? After a SQL patch? After a migration? After a new hire?

Also, I’d add who is feeling the pain and who is affected the most. Maybe it’s one or two people in the Accounting department. Maybe it’s the CFO trying to run a quarterly report. Or perhaps it’s your customers or partners who rely on access to your data outside your company.

That gives the consultant some context to work with.

You know your business better than any consultant walking through the door. That context is where a good diagnosis starts.

Understand your data landscape

You don’t have to know every nook and cranny of your SQL Server environment, whether it’s running on-prem or in the cloud. But you should have a baseline understanding of how things are put together.

Things like SQL Server versions and editions, if you know them, can provide useful information about your environment. Have an approximate idea of how many servers are affected, or maybe the percentage compared to the total number of servers. Is the issue only happening on your on-prem servers, or are your cloud instances affected as well?

Those are a few important things for the consultant to know as a starting point.

One thing worth checking first

If you check nothing else, check this: do your backups actually work? Or do you even have the right backup strategy in place?

If you don’t have RPO and RTO defined (or worse, don’t know what those mean), put that at the top of your discussion list with your consultant. This is one of the most important things you need to get right.

Not "is the backup job running?" That’s not the question. The real question is whether you have ever restored a backup and confirmed that it actually works.

A backup that has never been tested is just a hope, not a safety net.

Okay, somebody said that before. I’m just borrowing it here because it perfectly describes why testing your backups matters. 😉

If you’re not sure, that’s okay. That’s exactly the kind of thing you want to identify early. And honestly, it’s one of the first things I would want to understand as well.

Sort out access and ownership

Well, how can the consultant help if they don’t have the access level needed to do the work or accomplish what you brought them in to do?

Nothing slows down a first week like waiting on permissions. Before you bring anyone in, it helps to know who owns the SQL Server environment today (sa is the wrong answer ). Who can grant the access they need? Does it require a chain of approvals from higher-ups? Or is it an open-for-all kind of thing? The consultant needs to know if it’s the latter.

If you’re on a tight schedule or everything is already on fire, you don’t want to delay troubleshooting and resolution just because of access issues.

If you’re technical, go deeper maybe

If you or someone on your team is hands-on, here’s the bigger picture a DBA would typically look at. None of this is required. It is just useful information to have if you can pull it together.

Hopefully, Query Store is enabled. And if you’re lucky, it has enough history captured that you can correlate the data with the actual issues you’re seeing.

Disk latency,...