Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
Log in  ::  Register  ::  Not logged in

Performance Tuning Through Panic

By Steve Jones,

We've all been there at one time or another: panicked by a performance issue. I once upgraded a FoxPro for DOS application to a VFP front end with a SQL Server back end. We had a much more powerful server, generations ahead of the previous file server share. When the first users logged in and searches ran slower, I was in a panic. My team worried about the size of our inventory data in memory and quickly upgraded our 4GB, 1996-era server to 8GB of RAM, hoping for improvement. We also hurriedly split out queries and separated some data in an effort at quick tuning. It wasn't much above a knee-jerk reaction, but we had users, and management, yelling at us on an hourly basis.

I'm sure many of you have had other performance problems that resulted in some panic during your career. I've had more since then, and will probably have more in the future. Many of us do, and many of us perform knee-jerk performance tuning. However you can, and should, avoid tuning in a panic, as pointed out by Paul Randal. Doing so usually doesn't fix the problem, and when it reoccurs, it's more embarrassing with people less likely to listen to your next great idea.

Tuning a system is a science, but it's a complex science. Without experience, without having knowledge about all the complex interactions, and a deep understanding of how all the parts fit together, it often looks like a hopeless task. Who can keep all that information in their head and relate all the various components of the application? The network, the OS, the SAN, clients, all can cause problems that appear to be in the database.  As Paul points out, failing to understand the actual root cause can lead you to make changes that will have no effect on the actual underlying issue. You'll often realize this when the problem re-occurs in a short time.

I think one of the best reason to hire consultants is that they see so many problems that they can recognize patterns in performance that many of us don't see. What they do appears to be an art because they can seemingly understand what information is relevant, and what isn't. They walk down a list of potential issues, gathering evidence in a logical way, but one that can appear random to someone with much less knowledge and experience.

All of us can learn more, we can read about problems others have had and learn how they solved the issue. However we often face the same reaction that many consultants do: no one wants to implement the advice. Until clients and vendor are willing to tune their code, many problems will only be masked by hardware.

For a time. Then they'll reappear.

Total article views: 325 | Views in the last 30 days: 2
Related Articles

performance problem

performance problem


Replication - Performance Problem

Performance problem


Severe performance problems

performance problems due to "bad" statistics


Table partitioning and MAX queries performance problem

table partitioning performance problems


Problem with performance of query,DTS,jobs on SQL server 2005 after migration from 2000

Problem with performance of query,DTS,jobs on SQL server 2005 after migration from 2000


Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones