As I explained in "Duration and CPU Values" SQL Server Profiler captures duration times in microseconds and milliseconds. How you work with Profiler is different in SQL Server 2005 and 2000. Profiler aficionados know that Profiler running under SQL Server 2000 never shows a duration value that's between 1ms and 9ms, but you might see a 0 or a 10 and higher (for an explanation of why, see "Granular Timing Statistics From Profiler," August 2005, InstantDoc ID 46889). In contrast, Profiler running under SQL Server 2005 does capture duration values between 1ms and 9ms. To test this concept, you can play around with the following SQL batch code:

DECLARE @LoopMe int,@StopAt int
SET @LoopMe = 1
SET @StopAt = 425 
WHILE @LoopMe < = @StopAt
  SET @LoopMe = @LoopMe+1

This code is designed to make it easy for you to vary how long it should take to run a SQL batch. Simply vary the @StopAt column and run several tests.When I played around with this batch code under SQL Server 2005, I was able to generate duration values that included 1, 5, 6, 7, 8, and 9 milliseconds. Interestingly, the CPU value in SQL Server 2005 is still limited to values of 0ms or 10ms and higher.

You might wonder if anyone really needs to see values at that level of granularity in Profiler data.The short answer is yes.For example, let's say ProcedureXYZ runs fast—it consistently takes 9ms. Sure, that's fast, but let's also assume that the procedure is going to scan a table that has a few hundred rows,so you add an index to improve the runtime to about 1ms. Adding an index might not matter in most cases, but what if you're running ProcedureXYZ 100 times per second? Well, 100 executions per second times 9ms per execution means you're using 900ms of duration time per second. That's 90 percent of your CPU on a single-processor box and 45 percent on a dual-processor machine. Adding the index gets processing time down to 1ms per execution and results in dramatically lower CPU utilization. I, for one, will put the extra duration granularity in Profiler to good use. I hope you do too!

End of Article




You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Does that mean SQL 2000 omitted the rows with a duration of 10ms or less? I just did a SQL 2005 trace for 20 minutes that genarating a whopping 25 GB of trace files. In SQL 2000 I could trace the same database for 1 hour and not top 2 gb of trace files. Needless to say 90% of my rows in my SQL 2005 trace have a duration of 0. Is this granularity difference the reason for my huge trace files?

dbyardi

Article Rating 5 out of 5

Jason, SQL Server 2005 traces have a different set of default events, so that could explain the difference. SQL Server 2000 does not accurately capture times below 10MS, but it will capture events that show 0MS for a duration. Hope that helps, Brian Moran Managing Partner; North America Solid Quality™ Mentors

DianaMay

Article Rating 5 out of 5

 
 

ADS BY GOOGLE