I recently ran across the following question on the Microsoft SQL Server newsgroup: "Which should give better SQL Server performance: a server with a single-processor 1.6GHz Pentium 4 processor with 1GB of RAM or a server with dual 700MHz Pentium III processors with 2GB of memory? The performance of my existing server is slow, and I'm looking to upgrade to a faster machine."
That seems like a reasonable and innocuous question. However, many of the answers to this post focused on treating performance symptoms rather than identifying and solving the underlying problem that made the questioner think he needed to upgrade his server. The answers reminded me that a lot of people approach performance tuning like the doctor in this old joke:
Patient: Doctor, it hurts when I press here.
Doctor: Then don't press there.
You don't want a doctor to only treat your physical symptoms; you want the doctor to figure out why it hurts and treat the problem, right?
However, few people treat the causes of their database performance problems. All too often, they shortsightedly focus on managing the physical symptoms of the performance problems. They might say, "My CPU utilization is high, so let's see which server will give me the best CPU throughput." Don't fall into that trap. Maybe CPU utilization is high because of some inefficient client or middle-tier code. Maybe you could fix the performance problem by addressing the application instead of worrying about the CPU throughput capacity on the server. I can't tell you how many times I've had customers invest a huge amount of money in a new server only to be disappointed when the application didn't run faster. Faster servers simply sit idle for longer periods of time when a slow application is the problem.
I regularly speak about this topic at conferences, and I'm not going to lie to you: Figuring out the underlying causes of a performance problem isn't always easy. And even if you discover the root problem, you might not be able to solve it. For example, perhaps the inefficient application is a third-party application, and you don't have the source code to make changes. But regardless of the circumstances, you should always begin by trying to identify the root causes of the performance problem.
Where can you start? Do yourself a favor and learn how to effectively use SQL Server Profiler. You'll be amazed at the information you can learn about your application in a short time. With Profiler, you can see what statements your application is sending to the server, letting you understand your application and identify which parts of it are slow—in more detail than you ever anticipated.
