August 21, 2006 at 9:29 am
Yeah and sometimes I think the increasing number of bloggs is actually responsible for more problems then they try to solve. To be blunt a 2Gb std edition is not a high performance system so this is unlikely to be relevent - notice also the "it just depends" Too often people pick up on snippets of information, missunderstand, and then apply as what they think is a fix and actually cause more problems.
You need to know exactly what is causing the cxpacket locks/waits before making changes - my experience over the years has shown this to be poor application/database design/code and in 99% of the time can be resolved by effective indexing and more efficiant sql code.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
August 21, 2006 at 11:18 am
In my case, I see CXPACKET waits while rebuilding indexes. The other CXPACKET waits could well be due to design and code. However, a setting change or hardware update is a lot cheaper and easier than herding cats.
RandyHelpdesk: Perhaps Im not the only one that does not know what you are doing. 😉
August 23, 2006 at 4:35 am
To be honest making changes to server settings to resolve parallelism is akin to removing 6 spark plugs from your V8 to avoid going over 30mph in a built up area.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply