“Can you please open a ticket with Microsoft for our SQL Server?” – Perhaps one of the scariest requests ever when I was a full-time DBA or SQL Server consultant (though, as a CEO I may be tempted to say, “Hey it’s billable, bring it on!” ) If you’ve ever gone through the process – you know it’s a process… Yet, here at Straight Path, we sometimes have to open tickets with the SQL Server Support team for our DBA as a Service clients.
Well, it’s a thing you sometimes have to do. I thought I’d share some tips that have helped me out over the years.
6 Things To Do Before You Call SQL Server Support
1. Check Your Patch & Version
What release of SQL Server are you on? Ask yourself these questions:
- Are you on a version of SQL Server still in mainstream support or at least extended support?
- If not – how difficult is it to get there?
- Are you up to date with your patching? Quite often a CU or SP + CU have fixed the error you are having. One of our “policies” here is check that first and see if the problem persists. Read the KB articles for the next patch levels and see if your problem is there. While you are at it, read my blog posts about SQL Server patching and get into a consistent rhythm here.
If you aren’t on the latest CU/SP – It’s quite likely that support will first ask you to recreate the problem on the latest and decide to go from there based on your experience. If you are out of mainstream support or a couple of versions back, their answers will be more of a “best-effort” style. So you may get through all of that prep work, waiting, time, back and forth and still have to apply the patch anyway.
2. See if You Can Recreate the Issue
Did you have a single stack dump? Has it not happened since? Maybe hold off and see if it happens again before calling. Or see if you can make your problem happen on command before calling. They are going to want to see this happen. And you are about to invest considerable effort. In some circumstances, it could be worth the process for a single issue with no recurrence, but that’s not been my usual experience.
3. Troubleshoot First
Use troubleshooting best practices. Look at all of your logs. Hit your favorite search engine, consider search on twitter, consider the #SQLHelp hashtag on twitter, check out DBA.StackExchange. Try and see if it happens on your test server and your prod server. Experiment some with solving the issue yourself. You may solve it – or you will at least have a lot of information at your disposal to give to the support engineers to help them direct you properly.
4. Clear Your Calendar!!
The rumors and jokes are true. There is some back and forth. Support will have you run various data collectors and upload output. You are going to have to explain things, join calls, answer questions (sometimes 5 times see #5). Make sure you have the time to give this.
5. Find Patience! (And your runbooks)
You will be asked the same questions a few times. You’ll need to answer all of the questions about version, CU level, windows level, hardware resources, etc. You may even need to answer those questions more than a few times as you are passed around from team to team and level to level.
6. Self-Advocacy (And eyes wide open)
Watch the team names in the titles of the support teams. Make sure you are in the right team. If you are having an AG issue, and it is clearly not a storage or windows HA issue – but a problem deep in AG internals, watch the titles of the resources support teams send you to. Why would you need to be on the Windows HA team or storage team if you’ve not telegraphed that? Advocate for yourself. Don’t be afraid to ask for the right team. Don’t be afraid to follow up with the rep assigned. Don’t be afraid to ask for escalation if you feel like you are not getting anywhere. The phone is also your friend here.
Conclusion
Anyway – just a few things that have helped. I love many of the folks in support and they are amazing and helpful and I’ve learned many things from them on each call. But there are times when I want to do anything other than answer the same question over and over or plead for escalation or deal with getting tossed around from team to team. If your company is a big company and has been on the fence thinking about Premier Support agreements – DO IT!! Having a TAM is amazing. They are a wonderful resource to call and ask for help in routing your SR around – but you only get one if you are in that kind of agreement.