2010-02-11 9 views
24

Basado en conseguir ejecución de la consulta Estadísticas usando esta pieza muy útil de SQL obtenida de este post Most Executed Stored Procedure - Stack Overflow:Cómo CLEAR ejecución de la consulta Estadísticas en SQL Server 2005/2008

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 

¿Cómo me completamente claro a cabo estas ejecución estadísticas y comenzar desde cero?

Esto sería particularmente útil ya que los errores de desarrollo y las pruebas han provocado que las rutinas se llamen una gran cantidad de veces, invalidando los niveles de uso real.

Respuesta

49
DBCC FREEPROCCACHE 
DBCC DROPCLEANBUFFERS 
+3

Pero cuidado en la producción .... –

+0

Eso funcionó en el entorno de prueba. ¿Hay algún riesgo de hacerlo en la producción? –

+1

Sí, aunque aparece como errores de desarrollo y pruebas, por lo que, a menos que estuvieran probando/dev contra prod, debería estar bien. En producción, aumentaría mucho la CPU pero se recuperaría. – Andrew

Cuestiones relacionadas