Medir con precisión el rendimiento del procedimiento almacenado

Question

¿Cuál es la mejor manera de medir con precisión el rendimiento (tiempo para completar) de un procedimiento almacenado?

Estoy a punto de comenzar un intento de optimizar un procedimiento almacenado de monstruos, y para determinar correctamente si mis ajustes tienen algún efecto, necesito algo para comparar el antes y el después.

Mis ideas hasta ahora:

• Buscando un tiempo de ejecución de la consulta SQL Management Studio: No es muy precisa, pero es muy práctico.
• Agregar temporizadores en el procedimiento almacenado e imprimir el tiempo transcurrido: Agregar código de depuración como ese apesta.
• Uso del Analizador de SQL Server, agregando filtros para orientar solo mi procedimiento almacenado. Esta es mi mejor opción hasta ahora.

¿Alguna otra opción?

Answer 1

Profiler es el método más confiable. También puede usar SET STATISTICS IO ON y SET STATISTICS TIME ON, pero estos no incluyen el impacto completo de las UDF escalares.

También puede activar la opción "incluir estadísticas de clientes" en SSMS para obtener una visión general del rendimiento de las últimas 10 ejecuciones.

Answer 2

Una posible mejora en la opción de temporizadores/depurar es almacenar los resultados en una tabla. De esta forma, puede dividir y dividir los datos de tiempo resultantes con consultas SQL en lugar de solo analizar visualmente su resultado de depuración.

Answer 3

Hay un montón de información detallada del rendimiento en el DMV dm_exec_query_stats

DECLARE @procname VARCHAR(255) 
SET @procname = 'your proc name' 

SELECT * FROM sys.dm_exec_query_stats WHERE st.objectid = OBJECT_ID(@procname) 

Esto le dará los datos de rendimiento y los recuentos acumulativos de ejecución por la declaración en caché.

Puede usar DBCC FREEPROCCACHE para restablecer los contadores (no ejecutar esto en un sistema de producción, ya que purgará todos los planes de consulta en caché).

Usted puede obtener los planes de consulta para cada declaración mediante la extensión de esta consulta:

SELECT 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) [sub_statement] 
     ,*, CONVERT(XML, tqp.query_plan) 
FROM sys.dm_exec_query_stats qs CROSS APPLY 
    sys.dm_exec_sql_text(sql_handle) st CROSS APPLY 
    sys.dm_exec_query_plan(plan_handle) qp CROSS APPLY 
    sys.dm_exec_text_query_plan(plan_handle, statement_start_offset, statement_end_offset ) tqp 
WHERE st.objectid = OBJECT_ID(@procname) 
ORDER BY statement_start_offset, execution_count 

esto le dará indicaciones sobre qué partes de la SP están realizando mal, y - si se incluyen los planes de ejecución - ¿por qué .

Answer 4

Quiere asegurarse de que está realizando pruebas justas, es decir, comparando cosas similares. Considere la posibilidad de ejecutar sus pruebas utilizando un caché frío para forzar la ejecución de su procedimiento almacenado desde el subsistema IO cada vez que realice sus pruebas.

Tome un vistazo a los procedimientos almacenados del sistema DBCC FREEPROCCACHE y DBCC FREESYSTEMCACHE