Your SQL Server is slow – but should you call us in? Jeremiah and Brent had a throw-down the other day, and we figured we’d capture it here on the blog.
Brent Says You Do, and Here’s Why
5. You’ve been blindly throwing money at the problem without results. You’re on a first name basis with your local SAN salesperson. Your server racks are glistening with blue and green lights. But somehow, when users hit your app, they’re not as happy as your sysadmins – or your SAN salesperson. Before you burn another stack of Benjamins, it’s time to get an outside opinion.
4. You’re doing something for the first time. Sure, you’re pretty good at Googling your way out of trouble, but the company’s starting to make riskier and riskier gambles on data storage. Maybe you should talk to someone who’s faced this problem before.
3. You’re relying on the manual. I love Microsoft as much as the next guy – especially now that they brought out a new ergonomic keyboard – but Books Online doesn’t tell the whole truth. When Microsoft unveils a new feature, they talk about all the positives, but they don’t always disclose the drawbacks. Get a reality check before you bet the farm on PowerFilePivotProRT, and hear what our other clients are doing to accomplish the same goal.
2. You need answers faster. We get together on a Monday, and by end of day Wednesday, you’ve got a prioritized action plan showing you how to make the pain go away by the end of the week. You get the knowledge and confidence to keep going without expensive long-term consultants. You’re really close – you just need our 3-day SQL Critical Care® to unlock the tips and tricks to make it work.
1. Developers can get back to adding features. Your real business isn’t SQL Server administration – it’s adding features to your app to make your end user happier. Bring us in, get the answers, and get back to work.
Jeremiah Says You Don’t, and Here’s Why
5. You’re probably blindly throwing money at the problem without results. Unless a consultant is willing to provide a list of happy customers, there’s no way to verify that they know something. Heck, even if they do provide a list of happy customers, you have no way of knowing that Luanne in IT management isn’t really someone’s Aunt Mavis.
4. Best practices aren’t universal. Every situation is different and the most complicated scenarios require a deep understanding of business goals, features, and SLAs. Consultants can help you understand best practices, but you’re the only person who knows what’s right in your environment. If you’re doing something for the first time and your Google-fu is running out, you can’t expect much help from outside.
3. Peer pressure shouldn’t change your decisions. We jokingly call this “design by Hacker News”. Just because a startup, our clients, or your next door neighbor are doing something, that doesn’t mean it’s the right fit for you. For many application feature decisions, it’s easy to build two or three prototype solutions and decide on the best one.
2. You need performance yesterday. Rather than wait a few weeks for a reputable consultant to show up, have you considered buying memory? If you’re on SQL Server Standard Edition and you have less than 64GB of memory, just buy more RAM. If you’re on EE and you have less RAM than you have data, why not max out that server with 16GB DIMMs; they’re cheap and you can solve most code sins with memory. Heck, we even recommend buying memory as one of the first ways to solve problems quickly.
1. Developers: understand your features. While developers should be adding features, they also need to understand the consequences of those features. Some functionality that’s possible in SQL Server requires an understanding of how to write queries to take advantage of those features – filtered indexes, indexed views, and ColumnStore indexes immediately spring to mind. The best way to understand a feature is to get in the database, make it work, and then make it work fast.
10 Comments. Leave new
What about a case where your SQL server is totally dedicated to a 3rd party application. That vendor “says” settings should be certain way. No developers on site. Performance ok but could use improvement. You have baselines for multiple metrics but vendor does not want to “experiment” with any changes. They have there own benchmarks and as long as you fall in there, all is well….. don’t tinker…. Unless you want to add RAM or other hardware, which may have nothing to do with the metrics in question.
Greg – let’s zoom out with a question. Are the users complaining, and do they want you to focus on making this app faster?
I work for a vendor (I work for a 3rd party application) and I can identify with this scenario. Sometimes yes, performance suffers to the point of an application is deemed unavailable. It’s rare thankfully, but we treat it seriously. And we work with clients to make things right. In this case. For clients in this situation, I know I always appreciate a clear assessment of impact. And any data gathered including theories. I guess now it’s time to test how well you’ve built a relationship with the vendor.
And every now and then we hear suggestions or less pressing issues from clients. I think that it’s important to include business cases here. Hearing compelling business cases gets results faster (BTW, A web page returns in 2 seconds vs. 5 seconds is compelling to us).
When I talk with the vendor I let them know how the end users are being affected, how I’m measuring that impact and how I think it could be improved. I always offer to be a test site for changes and I’ll take the responsibility for measuring any successes and failures.
They allow me to test but when I have some success they say they may incorporated the change or recommend the change in future updates. They say I should change the setting back as the new setting is “unsupported” or I don’t get any comment at all…
Changing Vendors isn’t an option (yet….) so, to satisfy the end users, I keep the new settings but document ALL aspects as I can in case it ever comes back to bite me. I do this with successful as well as failed results.
Yes, the users complain. We’re dealing with electronic health records. Any delays, outages, etc. is unacceptable and it’s 24/7 as when the Docs are at Hospitals and need to access records/notes/lab results, etc. from our system. The application runs a LOT of ad-hoc queries…….
Then there you go – it’s time to focus on performance. 😉
Sounds like Greg has a problem visibility ‘problem’. If he is the only one who wants to solve the problem, and the vendor isn’t being supportive, and if the upper management isn’t pushing the vendors, then he’s done what he can do. If there is anything I hate is spinning my wheels trying to solve a problem, offering solutions, and then the power players don’t move on it. This is after all the charts, diagrams, etc.. to show how it will improve performance. I know upper managers think in terms of dollars, but it is hard to show how increased performance can sometimes = dollar savings when you are a developer or admin without some of the financial information.
Also on the terms of when to hire a consultant, I always feel like either management thinks you should know everything and if you suggest an ‘expert’ they will respond with ‘I thought you were the expert’. So it gets tricky to suggest that. Also, when you are running substandard systems and they want you to make them run like high end systems and not listening to all the good recommendations that Jeremiah has suggested, you know that an expert will come in and say what the hay is going on here.
The best line in here: “Developers: understand your features.”.
This should probably be followed with “Developers: learn how to design and implement set-based RDBMS solutions”. 🙂
Whatever, I want that keyboard ASAP… do they have a mechanical version?! If yes, byebye to my Das pro keyboard…XD