I ran across Denny Cherry’s (@MrDenny) blog on Fixing Vendor Performance Problems in which he outlines three methods of dealing with the. His list is basically
- Work with the vendor
- Do nothing
- Fix it yourself
Denny recommends that you do #3, and add indexes, statistics, etc., and script them so that you can drop them if the vendor needs to access the database, and add them back afterwards. This is done to avoid voiding a service contract.
I’ve done that in the past, but I try to avoid it. My first inclination is always to choose #1. I have had great success with this in the past, with a number of vendors, and it’s the item I recommend. Try to work within the system and make change, rather than just go "cowboy” right away and make the changes you think need to be made. I’ll give you the how and why I recommend this.
How
How do you get the vendor to make changes? The same way you get the best support you can from a vendor: you have a logical and rational discussion, explaining your thoughts with backing documentation.
I have had vendors insist that the “sa” login was needed, and avoided it. I have fixed performance problems by getting vendors to add and drop indexes. I have convinced vendors that they application could run, and be supported, on an instance with other databases.
All of this has been done with tracing the calls, analyzing performance, and then explaining where I saw issues with the vendor’s application. lt wasn’t done to prove I’m right, it wasn’t done to tell the vendor their code was sh*t, It was always done with me in the middle, along with the support person, between my boss, and their boss.
Talk to the vendor like he’s a friend coding in the next office, and he’s doing his best, but perhaps doesn’t understand why something isn’t working well. Give them supporting documentation, show them execution plans, show them before and after views on test systems, give them reasons why a chance is needed. Even offer to be a guinea pig for the tests. I’ve done that before, and we convinced a vendor that they didn’t need to index every column in a few tables based on six months of evidence from our system.
If they argue with them, perhaps they have good reasons. Get them to prove to you that they have logic and evidence on their side. They might, but if they don’t, then you ask to talk to their manager, or their development lead, and work through the argument there. Most vendors don’t want crappy performance, but as Denny mentioned, they often just don’t have expertise.
Work with them, not against them.
Why
Why should you spend time educating and teaching the vendor about SQL Server performance? Obviously you want to maintain your support contract status. There’s nothing worse than violating this and then having a problem that doesn’t get supported. That’s an ugly conversation to have with your boss.
You also don’t want issues with upgrades. I have seen more than a few problems with upgrades because someone “touched” the system. Make sure that you not only document the changes, but get the vendor to document them in your account. They might even work with you on upgrade scripts.
Lastly, you want to be right. There are plenty of people out there that make mistakes, or make a decision based on an incomplete picture. You might be sure that an index is needed for this query that runs every day, but maybe the vendor tested it and found a better index, or they found it caused worse performance for some other queries. Maybe you’re misreading the evidence yourself.
If you are forced to explain yourself, and can do so in a way to convince someone else, you should have more confidence that you are making the correct decision.
Plus it gives you something to blog about and put on your resume. 
Filed under: Blog Tagged: sql server, syndicated 
