Survey: what are the most common causes of performance problems?

This survey follows on from the survey results I just blogged about, and is particularly apt given we're here in Dallas this week teaching our Immersion Event on Performance Tuning.

I'm interested to know the root causes of your last few performance problems. I know that we all debug multiple performance problems every week, so have a think about the issues you debugged over the last week or month and vote a few times (or as many times as you want) to reflect the eventual root cause that was determined.

In the second survey, I'd like your opinion on what the most common cause of SQL Server performance problems is. Slightly different way of looking at things, and it'll be interesting to see how the results differ from the first survey.

Please vote as many times as you want on the first survey – free survey website only allows ten choices and no multi-select – but only vote once on the second survey.

(Damn – forgot to tick the box for 'Allow other' as a response – feel free to leave a comment with another response!) 




I'll report on the results in a couple of weeks.

Thanks!

9 thoughts on “Survey: what are the most common causes of performance problems?

  1. Too bad for no multi-select so I did like you said and voted multiple times. The performance issues I’ve dealt with lately are really a combination of things. Mostly bad t-sql code and bad index design. Of course if the t-sql were written differently there may not be a need for the indexes that were missing and likely other indexes would’ve been needed. Unfortunately there is no project DBA and I get called after the fact to fix what’s broke. Slowly, very slowly, I may be convincing those "evil developers" ;-) the ways of SQL Server development.

  2. I’m going to say "complex requirements". We sell off-the-shelf BPM software, which has to be very dynamic. Admins can create custom fields, users can search using any combination of fields they want, and the system has to enforce record-level access control. So, we have to work constantly to improve performance for new usage patterns without hurting the ones that we’ve already optimized.

  3. For the first survey, I voted for CPU power saving, Other hardware or OS issue, Poor indexing strategy, Out-of-date/missing statistics, SQL Server/database configuration, Database/table structure/schema design, Application code, and T-SQL code.

    It’s been a real busy week.

    Other hardware or OS issue = out of date nic drivers
    SQL Server/database configuration = poor implementation of peer-to-peer replication
    Database/table structure/schema design = clustered, non-sequential GUIDs (fragmentation > 99% on heavily used tables)
    Application code = not closing connections, running out of threads in connection pooling

  4. Thanks for doing these surveys Paul. It’s always interesting to see (1) what others experience and perceive compared to myself and (2) your analysis of the results.

  5. The choice I think is missing is "Bad developer" that would encompass bad T-SQL, DB Design, Indexing, etc.

  6. You didn’t say we could vote twice on the second survey so I had to hem and haw for about 8 minutes between I/O subsystem, DB Design and T-SQL Code. That one was a really tough choice :-)

  7. This week we saw "SQL" issues due to misconfigured firewall servers. It woan’t the first time we have seen this. We have also had issues with System Admin patching servers without notifying the DBA team. (ie rebooting server after patching, and leving all the instances on one node of teh cluster)

  8. "What were the root causes of the last few SQL Server performance problems you debugged?" – users. Specifically, the development team on the other side of the pond who decided it would be a good idea to hook into our main production application database and grab a shedload of data right at the busiest part of our working day.

    *BLAM*

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.