So your manager’s got some money burning a hole in her budget, and she wants you to go out and buy a management or monitoring tool.
Don’t ask, “How much overhead does this software have?”
Asking this question is a lot like saying, “Gosh, I sure would like to read a book to learn, but how long will it take to read?” I bet your SQL Server has at least 3-5% CPU available most of the time, and that’s a typical number for a monitoring tool to require. Besides, if your SQL Server is really running at 100% CPU, that is exactly when you need a tool to help. You do want to reduce the load on your server, right? That’s what a monitoring tool helps you do – identify the ugly queries, fix them in the least amount of time possible, and make your server healthier.
Every single time I’ve seen a good performance tool go in, the DBA has been able to quickly find performance problems they never would have caught otherwise in the same amount of time, then been able to fix those problems and reduce their server load by more than the load required by the monitoring tool. Game over.
Monitoring and management tools all have overhead. All of them. Every single one. It absolutely stuns me that the very same DBAs say these same two sentences:
- “Hey, Mr. Developer, you need to move your code into stored procedures rather than ad-hoc queries so I can improve performance.”
- “Hey, Mr. Vendor, you shouldn’t leave any code in my database server because that’s overhead.”
See the conflict? Properly-engineered databases and stored procs can be a much faster way of gathering data than pushing ad-hoc code and output data all over the place. (Note that I said properly-engineered – this is not a blog post about why vendor code sucks, and before you go throwing stones, let’s open up your code, Einstein.)
Here’s the worst part: the vendors all know what you want to hear (“zero overhead”) so some of them will actually tell you what you want to hear.
They’re lying.
Some tools even take it to the next level by hiding their own overhead in their performance reports. If you look at any performance tool’s report and you don’t see queries from the performance tool itself, ask why – because they’re probably hiding it from you. That’s bad, because you can bust your hump tuning your own queries only to find out that the tool itself is a bottleneck! Thankfully, that’s an exception rather than the rule.
Ask instead, “How do you gather your data?” Ask them to list DMVs, system tables, traces, and any other collection methods. If you download a demo, trace what it’s doing. When in doubt about the performance effectiveness or data accuracy, ask the community. Transparency is the best way to get the right answers about overhead and ensure that the vendor’s using the lowest-impact methods possible.
Don’t ask, “What’s coming in the next version?”
Like the stock people say, “Past performance is not an indicator of future outcomes.” Development dates slip, features get pulled out of the product at the last moment, and bugs get unearthed as the product’s going out the door. You probably don’t want to deploy any .0 versions on a production server, and it’ll take at least a couple of months to get the bug fixes released. Therefore, don’t gamble on the future version of any product – buy what’s out there today. Every software vendor is putting resources into vNext of their product. When your maintenance agreement is about to expire, revisit the market again.
Ask instead, “Can I see the supported SQL Server version list?” Supporting new versions of SQL Server is hard work – especially now that Microsoft’s starting to push out feature pack releases like SQL Server 2008 R2. You want to know if your vendor will support the latest and greatest SQL Server version, and how long it takes them to do it.
Don’t ask, “Does this software require SA access?”
One of the most eye-opening experiences I had working for a vendor was Microsoft telling me, “If you want to use the ___ feature in SQL Server, you have to be SA. End of story. No plans to change it.” Tweaking some security features doesn’t sell more licenses of SQL Server, and customers aren’t clamoring for it. As a result, the vendor is stuck requiring sysadmin-equivalent permissions in order to do ridiculously common tasks like back up a database via the VDI interface. As long as even one tiny part of the third party product requires SA privileges, then the whole thing does.
Ask instead, “Does this software use the SA account?” While the software might need sysadmin-level privileges, it should not require access to the SA account itself. You should be able to create a separate login for this software, make an absurdly complex password, and lock it away in a vault. This makes security audits and whodunit investigations much easier.
If you like my blog, you'll love my SQL Server classes. Check out my upcoming training events here.