views:

144

answers:

3

Hello,

I am struggling with a strange problem using Sql Profiler. While running some performance testing scripts, I run profiler to find bottlenecks. One particular statement seems to be taking a lot of time - with CPU 1407, Reads 75668 and Duration of 175.

However when I run the same statement in Management Studio, SQL Profiler returns CPU 16, Reads 4 & Duration 55.

Can anyone point me towards what I am doing wrong, as I am completely baffled by this.

Thanks, Susan.

+3  A: 

You may have a scalar user defined function that has table access.

The resources used are only picked up by profiler: SSMS won't show the internal IO or CPU of the scalar udf.

Example:

CREATE FUNCTION dbo.MyUdf (
    @param int
)
AS
RETURNS int
BEGIN
    RETURN (SELECT MAX(foo) FROM dbo.MyOtherTable WHERE Key = @param)
END
GO


SELECT
    col1, col2, dbo.MyUdf(col3)
FROM
    dbo.MyFirstTable

However, this may not explain duration...

gbn
+1 I wouldn't have thought of that.
Lieven
Thanks. It's a common gotcha and is effectively a CURSOR if you think about it...
gbn
I think it may be using a cursor as I'm seeing this in the sql traced sometimesexec sp_prepexec
@Susan: can you post the offending statement please?
gbn
We got a little more information, we found that the statement is called from a Java/Hibernate combination and something about the way the call is being made is returning 50,000 rows instead of the 2 rows returned when the statement is executed directly
@Susan: Interesting. Do you have more for us?
gbn
A: 

Was a java/hibernate issue.

A: 

If you run the query in enterprise manager directly after the profiling, all pages it needs will be cached in memory. This can lead to drastic improvements.

If you right-click the server in Enterprise Manager and select Properties, you can change the amount of memory available to the server. If you change this number even one step, SQL server will flush its cache.

erikkallen