The Trouble with Troubleshooting

Selling products that interact with SQL Server and Windows makes troubleshooting tougher: when people call in with problems, sometimes they’re not really related to our products.  Sometimes – heck, even often – the problem boils down to a Microsoft, hardware, or configuration issue totally unrelated to Quest products.

When our support team can’t get the right answer for the customer, they kick it up to the escalations team.  Escalations works with developers, product managers, and subject matter experts like me to drill deeper into issues.  This is when things get to be a little more challenging, because we have to ask questions about the customer’s environment – and sometimes we turn up answers that nobody wants to hear.

For example, I’m currently working with a customer who’s having trouble with their backups taking too long.  In the course of investigating the issue, we found that they were never purging their backup history in MSDB – ever.  The server had years and years of backup history, and as each backup job finished, SQL Server took longer and longer to update the history.  I’ve tried suggesting that native backups will also face that same problem, but the customer can’t try native backups – because they take even longer!  Ouch.

Awww, How....Cute?

Awww, How....Cute?

I’ve blogged about this backup bottleneck before, and SQL Server MVP Geoff Hiten has blogged about making MSDB backup histories faster, but I can’t seem to find a definitive article from Microsoft explaining the importance of this issue.  If it’s not in Books Online, some folks just don’t believe it – especially when it’s coming from a third party vendor like us.  Telling someone they have problems in their SQL Server environment is like calling their baby ugly; as far as they’re concerned, it’s all just a matter of opinion.

Tags:

One Response to “The Trouble with Troubleshooting”

  1. Mike Waddle Says:

    I can say for a fact that they would have seen the same problem with native backups. We ended up adding indexes to msdb and setting up purge jobs on backup history to solve this issue.

    -Mike