March 19, 2012 at 2:20 pm
Hi all, I've been taking a look around the Perf fora recently and comparing the scenarios to my own findings, and I was curious as to which types of solution you all have found are the most prevalent.
I'd say the following types of fix are most common, so imo, in descending order;
1) Code rewrite;
2) Memory/CPU upgrade;
3) SQL Server reconfiguration;
4) Disk System upgrade/reconfiguration
5) OS reconfiguration
6) Server/Service restart
Like I said, I'm curious to know if this agrees with (or how this differs from) your own experiences.
March 19, 2012 at 2:26 pm
1) SQL code changes
2) Indexes
3) Application code changes
4) Database config changes
5) Hardware upgrades (IO predominately, very hard to max out a modern CPU with well-written code)
Restarting SQL is not a performance fix. If restarting SQL improves performance then there's some config or code problem that needs to be identified and resolved.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 19, 2012 at 2:45 pm
GilaMonster (3/19/2012)
1) SQL code changes2) Indexes
3) Application code changes
4) Database config changes
5) Hardware upgrades (IO predominately, very hard to max out a modern CPU with well-written code)
Restarting SQL is not a performance fix. If restarting SQL improves performance then there's some config or code problem that needs to be identified and resolved.
Agree completely that restarting SQL is a quick and even dirtier method of brushing problems under the rug, and with #5 not including CPU, to be honest I hesitated in mentioning either.
I'm surprised at # 4 however, what database-level changes have you found most involved with improving performance?
March 19, 2012 at 2:56 pm
Jake Shelton (3/19/2012)
I'm surprised at # 4 however, what database-level changes have you found most involved with improving performance?
AWE on 32 bit instances (instance not database level), max server memory (instance not database level), forced parameterisation, optimise for ad-hoc workloads (instance not database level), snapshot or read committed snapshot. Turning off autoclose/autoshrink, fixing growth increments, fixing log fragmentation.
Huge gap between 3 and 4 though, and most of those are not for SQL 2000
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply