J'essaie de déterminer s'il y a un moyen d'identifier une "version" d'un SP qui s'appelle le plus. J'ai un SP qui est appelé avec un tas de différents paramètres. Je sais que le SP provoque des problèmes et essayons d'épingler le problème. En plus de capturer les appels vers le SP et de tamiscer manuellement à travers les résultats, est-il possible d'utiliser le profileur pour grouper des appels SP par des paramètres fournis?
Je ne suis pas un dB (A / E), juste un devis de développement, de sorte que les indices / points dans la bonne direction seront utiles. Merci!
EDIT: Recompilation Le SP n'en aide pas beaucoup.
4 Réponses :
Cela vous donnera les 50 Procs les plus importants et les déclarations de la part des Procs, à partir d'ici: Affichez les 50 procédures stockées les plus utilisées dans 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
oooh intelligent. Je n'ai jamais pensé à rejoindre la définition à la requête la plus utilisée
Je vais certainement essayer cela.
Comment obtenir la base de données spécifiée?
Si vous savez quel SP provoque que les problèmes ne pouvaient pas simplement enregistrer les paramètres qui lui sont passés à partir de ce SP? Vous pouvez configurer une table avec la liste des paramètres, puis la connecter à l'heure à laquelle la procédure a pris pour compléter, puis interroger ce tableau pour voir quels paramètres causent les pires performances.
On dirait que vous n'avez besoin que de pouvoir capturer ces informations pendant une courte période. La SPTRO peut être appelée un grand nombre de fois au cours de cette période, mais c'est une période finie.
Si tel est le cas, vous pourriez peut-être enregistrer les appels SproC quelque part? Si vous avez le contrôle sur le code SPROC, vous pouvez effectuer la journalisation là-bas. Une approche serait de créer un tableau spécial à cette fin, ajoutez un insert à cette table au début ou à la fin de la SPUCT existante et attendez que certains enregistrements s'accumulent dans la table .
Selon les spécificités, vous pouvez créer une colonne dans la table de journalisation personnalisée pour chaque paramètre SproC.
Ensuite, vous aurez des informations suffisantes sur l'utilisation de la SPROC, pour la période de temps que vous effectuez la journalisation.
Compte tenu des données accumulées dans la table, vous pouvez interroger pour rechercher les valeurs de paramètre les plus fréquentes, que les utilisateurs ou applications ou pages Web, etc. sont impliqués, les DateTimes du début et de la fin de l'appel SPROC, et quoi que ce soit Vous vous connectez.
Cela n'impliquerait aucune modification du code de l'application, et cela pourrait être complètement éliminé après avoir terminé votre dépannage. Donc, mis à part le succès de la performance inévitable de tout ce que l'enregistrement, le prix de cette approche n'est pas élevé.
Edit: Cette approche serait une alternative pour les utilisateurs qui manquent d'autorisations spéciales requises pour exécuter des requêtes DMV sur des tables telles que SYS.DM_EXEC_QUERY_STATS. Dans de nombreux magasins, obtenir de telles autorisations - en particulier sur les bases de données de production - n'est pas réalisable pour les développeurs.
Oui, cela pourrait certainement fonctionner. Lorsque vous posez la question, je pensais principalement à la manière du profileur SQL de capturer des choses.
J'aime cet extrait de code pour retirer et examiner les statistiques d'exécution. et le plan de requête en cache pour une procédure stockée donnée. Dans Management Studio, vous pouvez cliquer sur le XML renvoyé dans la colonne "Query_plan" pour afficher la version graphique du plan d'exécution.
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')
Dupliqué possible de Procédure stockée la plus exécutée?
Je ne crois pas que cela devrait être rejeté comme un DUP, car dans ce cas, ils recherchent des variations dans les paramètres du même SproC. L'autre question concerne les Sprat (s) les plus fréquemment appelés. Ici, nous savons quelle SproC a besoin d'attention. Ce sont les différents paramètres qui sont le problème. Et cela implique une approche de dépannage différente.