August 17, 2010 at 9:12 am
thanks robert ..the reason why i wanted to clear the logs is so that i can calculate fresh data from the time i have started my testing. And the result is anyhow cumulative, so any reason why you want me to calculcate at different points?
August 17, 2010 at 10:59 am
If I measure it at 10:50 AM and then again at 10:55 AM, I don't need to have reset the counters to see how much it has changed. I can simply subtract the values to ge the difference. This way I can determine the waits occured over any time range I've tracked.
August 18, 2010 at 7:16 am
1) search web for track_waitstats_2005 to get a very good script to do wait stats analysis by time-spread analysis.
2) I disagree with previous poster that CXPACKET waits dont' indicate a problem. They indicate that one or more CPUs are doing NOTHING USEFUL for their timeslice because they are SUPPOSED to be running a parallelized query but they have no data to process. That is lost work and is not good for the server, especially as that wait stat increases. This is a VERY VERY common scenario out there (seen at EVERY perf-tuning client I have had for the last 5+ years) because CPUs are abundant and IO performance is universally suboptimal.
3) It was my understanding that the optimizer would not even think about a parallel query plan if a) plan is trivial or b) serial plan(s) come out less than CTFP.
4) I also disagree with previous poster about MAXDOP 1 for OLTP. If said system is HIGHLY TUNED and is not a shared reporting system there is a good win for this configuration. $0.02 from the Guru - YMMV
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
August 18, 2010 at 10:24 am
Didnt knew this discussion so long, good for me though:-). I am also capturing context switches/sec as one of the counters for baseline. Just wanted to let you know.
Viewing 4 posts - 31 through 34 (of 34 total)
You must be logged in to reply to this topic. Login to reply