August 28, 2019 by Kenneth Fisher
I recently had someone tell me, and I’m paraphrasing a bit here:
We know how to fix this now, so all this discussion of why it (the fix) works is superfluous.
And that’s great in the short run. I mean we had to get production up and running again right? But what about next week when the problem happens again? It may not be on that server, or that database, or even that particular piece of code, but most problems turn up at least occasionally and without understanding not just how to fix it, but why it works we are just throwing possible solutions at a problem and hoping one of them sticks.
Just as an example “XYZ is slow, we need you to rebuild the indexes.” Why is that fixing your problem? Which index is the problem? I mean it’s probably not just one right Is an index really the problem or do the stats need to be updated? Or maybe it’s because when the stats are updated it’s invalidating the current query plan for one specific stored procedure. If you know exactly what’s going on you can recompile that one procedure, or even better work on tuning it so that you don’t have that particular problem in the future.
Fixing a problem is important. Figuring out what went wrong will help you solve it faster in the future, or even better stop it from happening again.