Forma más rápida de identificar la variación más utilizada del Procedimiento almacenado en SQL Server 2005

Estoy tratando de averiguar si hay una manera de identificar una "versión" de un SP que se llame más. Tengo un SP que se llama con un montón de parámetros diferentes. Sé que el SP está causando algunos problemas y tratando de identificar el problema. Además de capturar llamadas al SP y tamizar manualmente los resultados, ¿es posible usar el generador de perfiles para agrupar llamadas SP según los parámetros proporcionados?Forma más rápida de identificar la variación más utilizada del Procedimiento almacenado en SQL Server 2005

No soy un DB (A/E), solo un desarrollador web, por lo que cualquier sugerencia/punto en la dirección correcta será útil. ¡Gracias!

EDITAR: Recompilar el SP no ayuda mucho.

Fuente

2010-08-17 MK_Dev

posible duplicado de [más ejecutado procedimiento almacenado?] (Http://stackoverflow.com/questions/1942726/most-executed-stored-procedure) –

Yo no creo que esto debe ser rechazada como un DUP , porque en este caso están buscando variaciones en los parámetros para el mismo sproc. La otra pregunta es sobre qué sproc (s) se llaman con más frecuencia. Aquí, sabemos qué sproc necesita atención. Son los diversos parámetros que son el problema. Y eso implica un enfoque de solución de problemas diferente. – DOK

Esto le dará los 50 mejores procsos más utilizados y las declaraciones en los procs, desde este punto: Display the 50 most used stored procedures in SQL Server

SELECT TOP 50 * FROM(SELECT COALESCE(OBJECT_NAME(s2.objectid),'Ad-Hoc') AS ProcName, 
    execution_count,s2.objectid, 
    (SELECT TOP 1 SUBSTRING(s2.TEXT,statement_start_offset/2+1 , 
     ((CASE WHEN statement_end_offset = -1 
    THEN (LEN(CONVERT(NVARCHAR(MAX),s2.TEXT)) * 2) 
ELSE statement_end_offset END)- statement_start_offset)/2+1)) AS sql_statement, 
     last_execution_time 
FROM sys.dm_exec_query_stats AS s1 
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2) x 
WHERE sql_statement NOT like 'SELECT * FROM(SELECT coalesce(object_name(s2.objectid)%' 
and OBJECTPROPERTYEX(x.objectid,'IsProcedure') = 1 
and exists (SELECT 1 FROM sys.procedures s 
WHERE s.is_ms_shipped = 0 
and s.name = x.ProcName) 
ORDER BY execution_count DESC

Visita que enlazan a agarrar la consulta para sólo el nombre del procedimiento, pero creo que esto es una mejor consulta ya que le da las instrucciones en los procesos también

Fuente

2010-08-17 18:42:45 SQLMenace

oooh listo. Nunca pensé en unir la definición a la consulta más utilizada – gbn

Definitivamente voy a intentar esto. –

¿Cómo obtener la base de datos especificada? –

Si sabe qué SP está causando los problemas, ¿no podría simplemente registrar los parámetros pasados desde ese SP? Puede configurar una tabla con la lista de parámetros, luego registrarlos junto con el tiempo que tardó en completar el procedimiento y luego consultar esa tabla para ver qué parámetros están causando el peor rendimiento.

Fuente

2010-08-17 18:47:38 Jay

Parece que solo debe ser capaz de capturar esta información durante un corto período de tiempo. El sproc puede llamarse una gran cantidad de veces durante ese período, pero es un período finito.

Si ese es el caso, ¿podría registrar las llamadas sproc en algún lugar? Si tiene control sobre el código de sproc, puede realizar el registro allí. Un enfoque sería crear una tabla especial para este propósito, agregar un INSERTAR a esa tabla al principio o al final del sproc existente y esperar a que se acumulen algunos registros en la tabla.

Según los detalles, puede crear una columna en la tabla de registro personalizado para cada parámetro de sproc.

Entonces tendría amplia información sobre el uso de sproc, durante el período de tiempo que realiza el registro.

Teniendo en cuenta los datos acumulados en la tabla, puede buscar los valores de parámetros más frecuentes, qué usuarios o aplicaciones o páginas web están implicadas, las fechas para el comienzo y el final de la llamada sproc y cualquier de lo contrario, inicie sesión.

Esto no implicaría ningún cambio en el código de la aplicación, y podría eliminarse por completo una vez que haya completado su solución de problemas. Entonces, aparte del inevitable golpe de rendimiento de toda la tala, el precio de este enfoque no es alto.

Editar: Este enfoque sería una alternativa para los usuarios que carecen de los permisos especiales necesarios para ejecutar consultas de DMV en tablas como sys.dm_exec_query_stats. En muchas tiendas, obtener tales permisos, particularmente en las bases de datos de producción, no es factible para los desarrolladores.

Fuente

2010-08-17 18:47:53 DOK

Sí, eso definitivamente podría funcionar. Al hacer la pregunta, estaba pensando principalmente en la forma de capturar cosas de SQL Profiler. –

Me gusta este fragmento de código para retroceder y revisar las estadísticas de ejecución. y el plan de consulta en caché para un procedimiento almacenado dado. En Management Studio, puede hacer clic en el XML devuelto en la columna "query_plan" para ver la versión gráfica del plan de ejecución.

SELECT qp.*,qs.*,st.text 
    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 
    WHERE st.objectid= object_id('YourStoredProcedureName')

Fuente

2010-08-17 18:52:41

Forma más rápida de identificar la variación más utilizada del Procedimiento almacenado en SQL Server 2005

Respuesta

Cuestiones relacionadas