Suivi des procédures stockées

Question

J'ai mis en place une table de suivi des procédures stockées sur nos bases de données dans l'espoir de les utiliser pour débusquer les procédures que nous n'utilisons plus. Je l'ai mis en place il ya quelques mois, et je suis maintenant prêt à être en mesure de commencer le nettoyage. Les tables utilisent les DMV sys.procedures et sys.dm_exec_procedure_stats dans SQL Server 2008 R2, et un travail met à jour la table statique toutes les 10 minutes, 24 heures par jour

J'ai vérifié ma liste de procédures, et j'ai rencontré un couple que je savoir pour un fait ont couru très récemment. Celui que j'ai trouvé fonctionne comme l'étape 2 d'un travail, mais le sys.dm_exec_procedure_stats ne semble pas contenir d'enregistrement, mais la procédure de l'étape 1 est apparue au bon moment. J'ai vérifié l'historique des travaux et les deux étapes 1 et 2 se sont déroulées sans problème. La seule différence que je peux voir est que la procédure de l'étape 2 aboutit à un "Avertissement: la valeur nulle est éliminée par un agrégat ou une autre opération SET" alors que la première étape ne l'est pas. Cela fait-il une différence quant à savoir si la procédure apparaîtra ou non dans le sys.dm_exec_procedure_stats?

Espérons que quelqu'un peut vous aider!

Answer 1

Bien que la raison pour laquelle il n'apparaît pas dans le DMV est probablement la raison spécifiée dans la réponse liée/liée mentionnée par @ bastos.sergio dans un commentaire sur la question, qui laisse encore la question de "ce qui peut être fait pour trouver que les procs ne soient pas utilisés? ".

La réponse acceptée à cette question liée (ce qui est la question référencée par @ bastos.sergio: Last Run Date on a Stored Procedure in SQL Server) manque quelque chose donc je vais ajouter ici:

Le SEULEMENT façon de savoir ce que l'on appelle il est:

• scan tout le code (code de l'application, d'autres procédures stockées, étapes de travail [dans msdb.dbo.sysjobsteps], les fichiers de définition de rapport SSRS, etc.) pour les références
• Si vous autorisez l'accès ad hoc (par exemple, quelqu'un a référencé un Proc stocké dans un Ac app cess [ou tout Microsoft Office « app »]), alors vous devez faire certains des étapes supplémentaires mentionnées dans la réponse acceptée de cette question liée, à savoir:
  • Ajouter un RAISERROR(N'Deprecated! Please contact YourName.', 16, 1); RETURN; au sommet du proc et laissez-le là pour un mois ou deux.
  • Ajoutez une table pour consigner les appels proc et un INSERT dans cette table de journal en haut du code supposé obsolète et vérifiez une fois par semaine pour voir si quelque chose apparaît. Si vous faites aussi le RAISERROR, placez le INSERT avant le RAISERROR(...); RETURN;.
  • En ce qui concerne l'accès ad hoc (c'est-à-dire l'accès en dehors du code que vous contrôlez), veillez à toujours garder à l'esprit que l'accès peu fréquent peut être juste: peu fréquent. S'il y a un chemin de code qui est exécuté mensuellement, trimestriellement, semestriellement, annuellement, quand un gestionnaire se souvient de demander tel ou tel rapport, etc., alors vous pourriez potentiellement enlever le code valide si vous ne permettez pas un délai assez long l'intervalle de temps pour capturer l'utilisation «très» peu fréquente (et c'est pourquoi, même si les données DMV étaient plus fiables, vous auriez toujours besoin d'être aussi prudent).
  • Encore une fois, si tout l'accès est dans le code que vous contrôlez, il suffit d'analyser votre code (probablement en utilisant des expressions régulières).

EDIT:
Pour répondre à la question spécifique de:

Le "Attention: la valeur NULL est éliminé par un agrégat ou d'une autre opération SET" avertissant que la requête, courir dans le Proc mémorisé qui n'apparaît pas dans le DMV, obtient quelque chose à voir avec pourquoi il n'apparaît pas dans le DMV?

faites le test suivant:

CREATE PROCEDURE #NoWarning 
AS 
SELECT AVG(tmp.col) 
FROM (
    SELECT 1.0 
    UNION ALL 
    SELECT 2 
    ) tmp(col); 
GO 

EXEC#NoWarning; 
GO 

CREATE PROCEDURE #Warning 
AS 
SELECT AVG(tmp.col) 
FROM (
    SELECT 1.0 
    UNION ALL 
    SELECT null 
    ) tmp(col); 
GO 

EXEC#Warning; 

puis exécutez la requête suivante et vous devriez voir les noms de proc apparaissant dans "tempdb":

SELECT DB_NAME(ps.database_id) AS [DatabaseName], 
     OBJECT_NAME(ps.[object_id], ps.database_id) AS [ProcName], 
     * 
FROM sys.dm_exec_procedure_stats ps 
ORDER BY [DatabaseName], [ProcName];