Part 4. Performance tuning and optimization

Edited by Brad M. McGehee

For most of my DBA career, I’ve focused on how to get the optimum performance out of SQL Server. I started a website in 2000 that focused exclusively on SQL Server performance. I don’t think I’m alone in this regard. No matter where you look—blogs, forums, websites, conferences—the topic of SQL Server performance and optimization seems to be at the forefront. It’s no wonder, because the biggest complaints DBAs hear from users are related to slow performance.

The sad part is that SQL Server can be lightning fast. With few exceptions, SQL Server–related performance problems aren’t directly related to SQL Server itself but are related to other factors, such as inadequate hardware, poor configuration settings, poor database design, poor application design, poor indexing, poor database maintenance...the list goes on and on. SQL Server, the product, is seldom responsible for poor performance. Instead, it’s the factors outside SQL Server that are often to blame for less-than-optimal performance.

Unfortunately, the DBA is seldom responsible for all aspects of a SQL Server–based application. For example, one team might be responsible for spec’ing out the hardware, configuring it, and maintaining it. Another team might be responsible for the database design. And another team might be responsible for writing the code that accesses SQL Server. Many people play a part in how an application gets designed and up and running.