views:

268

answers:

2

Based on getting Query Execution Statistics using this extremely useful piece of SQL obtained from this post Most Executed Stored Procedure - Stack Overflow:

SELECT TOP 100
   qt.TEXT AS 'SP Name',
   SUBSTRING(qt.text, qs.statement_start_offset/2, CASE WHEN (qs.statement_end_offset = -1) THEN LEN(qt.text) ELSE (qs.statement_end_offset - qs.statement_start_offset)/2 END) AS actual_query,
   qs.execution_count AS 'Execution Count',
   qs.total_worker_time/qs.execution_count AS 'AvgWorkerTime',
   qs.total_worker_time AS 'TotalWorkerTime',
   qs.total_physical_reads AS 'PhysicalReads',
   qs.creation_time 'CreationTime',
   qs.execution_count/DATEDIFF(Second, qs.creation_time, GETDATE()) AS 'Calls/Second'
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
WHERE qt.dbid = (SELECT dbid
                FROM sys.sysdatabases
               WHERE name = 'BSP')
ORDER BY qs.total_worker_time/qs.execution_count DESC

How would I completely clear out these execution statistics and start from scratch?

This would be particularly useful as development bugs and testing have caused routines to be called an usually large number of times thus invaliding the true usage levels.

+1  A: 
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
Andrew
But careful on production....
Mitch Wheat
That worked in the test environment - are there any risks to doing this in Production?
Simon Mark Smith
Yes, although it's listed as development bugs and testing, so unless they were testing / dev against prod it should be fine. On production it would spike the CPU badly but recover.
Andrew
Answer awarded - thank you
Simon Mark Smith
A: 

Using DBCC FREEPROCCACHE will clear the procedure cache and remove all cached query plans.

It must be noted that this could have a performance impact, as SQL Server will have to compile all queries until the cache is up to size again.

kevchadders