Stored Procedure tracking - sql-server

Question

I have set up a stored procedure tracker table on our databases with the hope of using it to flush out procedures that we no longer use. I set this up a few months ago, and am now ready to be able to start the cleansing. The tables utilises the sys.procedures and sys.dm_exec_procedure_stats DMVs in SQL Server 2008 R2, and a job updates the static table every 10 minutes, 24hours a day
I have been checking through my list of procedures, and have come across a couple that I know for a fact have run very recently. The particular one I have found runs as step 2 of a job, but the sys.dm_exec_procedure_stats doesn't seem to contain any record of it having been run, but the procedure in step 1 has appeared at the correct time. I have checked the job history, and both steps 1 and 2 ran without any problems.
The only difference I can see is that the procedure in step 2 comes up with a "Warning: Null value is eliminated by an aggregate or other SET operation" whereas step one doesn't. Does this make a difference as to whether or not the procedure will appear in the sys.dm_exec_procedure_stats?
Hope someone can help!

Answer 1

While the reason that it doesn't show up in the DMV is likely the reason specified in the linked/related answer mentioned by #bastos.sergio in a comment on the question, that still leaves the issue of "what can be done to find procs not being used?".
The accepted answer in that linked question (this is the question referenced by #bastos.sergio: Last Run Date on a Stored Procedure in SQL Server ) is missing something so I will add to it here:
The ONLY way to know what is calling it is:
scan all code (app code, other Stored Procs, Job Steps [in msdb.dbo.sysjobsteps], SSRS report definition files, etc.) for references
IF you allow ad hoc access (e.g. someone referenced a Stored Proc in an Access app [or any Microsoft Office "app"]) then you need to do some of the additional steps mentioned in the accepted answer of that linked question, namely:
Add a RAISERROR(N'Deprecated! Please contact YourName.', 16, 1); RETURN; at the top of the proc and leave it there for a month or two.
Add a table to log proc calls and an INSERT into that log table at the top of any of the supposed obsolete code and check once a week to see if anything shows up. If also doing the RAISERROR, put the INSERT prior to the RAISERROR(...); RETURN;.
With regards to ad hoc access (i.e. access outside of the code that you control), be careful to always keep in mind that infrequent access can be just that: infrequent. If there is a code path that is executed monthly, quarterly, bi-annually, annually, when some manager remembers to ask for such and such report, etc., then you could potentially remove valid code if you do not allow a long-enough time frame to capture "highly" infrequent usage (and this is why, even if the DMV data was more reliable, you would still need to be just as cautious).
Again, if all access is within code that you control, just scan your code (most likely using Regular Expressions).
EDIT:
To answer the specific question of:
Does the "Warning: Null value is eliminated by an aggregate or other SET operation" warning that the query, running in the Stored Proc that does not show up in the DMV, gets have something to do with why it is not showing up in the DMV?
do the following test:
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;
And then run the following query and you should see both proc names appearing in "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];