From: SqlBeginner on
Eric based on the result i changed a SP for better performance and deployed.
Now if we run your query if my fix is correct it should go off from the list
asap right? or do i need to keep running for few iterations?

Regards
Pradeep

"Eric Isaacs" wrote:

> The previous version finds the slowest processes on the server that
> use the most CPU cycles. I tweaked it a little after I left that
> message. Now if you specify the database, this will provide the top
> slowest portions of different objects (sprocs, views, triggers, etc.)
> in that database. It's a little slow to run itself since it's calling
> a function, but it works.
>
> USE databasename
>
> SELECT
> query_stats.objectid,
> OBJECT_NAME(query_stats.objectid) AS [ObjectName],
> query_stats.Text,
> query_stats.statement_text AS [SQLText],
> SUM(query_stats.total_worker_time) /
> SUM(query_stats.execution_count) AS [AverageCPUTime]
> FROM
> (
> SELECT
> QS.*
> ,ST.objectid, ST.Text,
> SUBSTRING(ST.text, (QS.statement_start_offset / 2) + 1, ((CASE
> statement_end_offset
>
> WHEN -1 THEN DATALENGTH(ST.Text)
>
> ELSE QS.statement_end_offset
> END
> - QS.statement_start_offset) / 2) + 1) AS statement_text
>
> FROM
> sys.dm_exec_query_stats AS QS
> CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) AS ST) AS
> query_stats
> WHERE
> OBJECT_NAME(query_stats.objectid) IS NOT NULL
> GROUP BY
> query_stats.statement_text,
> query_stats.objectid,
> query_stats.TEXT
> ORDER BY
> SUM(query_stats.total_worker_time) /
> SUM(query_stats.execution_count) DESC ;
>
>
> -Eric Isaacs
> .
>
From: Eric Isaacs on
The whole query is based on what is in the cache. If you want to
determine how your new code ranks, I would suggest you clear the cache
to see how evenly compares with other SQL in the cache from a common
starting point. If you don't clear the cache, I really don't know if
it will remain in cache or not if the base object is recompiled. My
hunch would be that it would be replaced, but I haven't verified that.

Execute this statement to clear and therefore reset the SQL cache...

DBCC FREEPROCCACHE


Clearing the cache will allow you to have a common starting point for
SQL in the cache. After you clear it, give it some time and then run
the test SQL again later after the cache has been rebuilt. If your
code is back in the list after doing everything you can to get recode
it to speed it up, it very well could be an indexing issue that you
need to look into resolving. Recoding doesn't always do the trick,
manytimes, you need a better index design to speed things up to sub-
second results.

-Eric Isaacs
From: SqlBeginner on
Thanks for explanation Eric.

Regards
Pradeep

"Eric Isaacs" wrote:

> The whole query is based on what is in the cache. If you want to
> determine how your new code ranks, I would suggest you clear the cache
> to see how evenly compares with other SQL in the cache from a common
> starting point. If you don't clear the cache, I really don't know if
> it will remain in cache or not if the base object is recompiled. My
> hunch would be that it would be replaced, but I haven't verified that.
>
> Execute this statement to clear and therefore reset the SQL cache...
>
> DBCC FREEPROCCACHE
>
>
> Clearing the cache will allow you to have a common starting point for
> SQL in the cache. After you clear it, give it some time and then run
> the test SQL again later after the cache has been rebuilt. If your
> code is back in the list after doing everything you can to get recode
> it to speed it up, it very well could be an indexing issue that you
> need to look into resolving. Recoding doesn't always do the trick,
> manytimes, you need a better index design to speed things up to sub-
> second results.
>
> -Eric Isaacs
> .
>