Professional Microsoft® SQL Server® 2008 Programming

Chapter 21. What Comes After: Forensic Performance Tuning

Well, wouldn't it be nice if we could just develop the software, get paid for it, and forget it...? Yeah, well.... You can stop dreaming now — it just doesn't work that way.

At some point, any software we consider to be part of a successful development project is going to get rolled out in front of some user base. Even if it's just a prototype, we're going to be analyzing how the prototype matched our original goals. Part of assessing whether we met our goals is taking a look at performance and asking ourselves what we could be doing better.

In the previous chapter, I suggested that the most important thing to understand about performance tuning is that you are never going to know everything there is to know about it. If I were to come up with a competing idea for "most important thing to understand," it would be that you are never really done with performance tuning. The content of your system will change, the state of your server will change, the use of your system will change. In short, the overall system will change, and that will affect performance. The trick is to understand what's working poorly, what's working well, and what's working "well enough."

Just as we did the previous chapter, we're going to be roaming around quite a bit in terms of the topics covered. Everything we talk about is going to be performance related in some fashion, but this time we'll be more focused on figuring out what is hurting performance. ...