SQL Server 2008R2 sys.dm_exec_procedure_stats - unusual last execution time

Question

I have a job which captures data from sys.dm_exec_procedure_stats. The job runs every minute. It is a straight insert from, no joins. I'm have a scenario where, quite regularly ( exactly the same two days every week without fail) one particular object id returns something like below

timeOfCapture /LastExecutionTime

16:58 / 16:30

16:59 / 16:30

17:00 / 16:30

17:01 / 17:00       (no explanation)

17:02 / 16:30       (no explanation - back to normal)

17:03 / 16:30

The stored procedure is invoked by a job which started around 16:30 The stored procedure did NOT run at 17:00 (as far as I know). There is a job which starts at 17:00 but does not execute this stored procedure. The stored procedure takes about 30 seconds to complete.

the object id is the same for all, the database id is also the same.

The fact this occurs regularly without fail means perhaps there is another process

I don't know if there's anything going on like reboots etc I'm also not sure if there is an external process ( other server/ excel/etc) that maybe invokes the stored procedure, or maybe there's a rollback.

thid could be a red herring, something I've overlooked, but I've checked everything I can think of. Any ideas on those LastExecutionTimes?

Thanks

Answer 1

That DMV contains one row for each cached stored procedure plan , and the lifetime of the row is as long as the stored procedure remains cached. This means that a stored procedure can have multiple rows in this table, or none at all if they don't have a plan in cache. The last_execution_time corresponds to the last time that procedure was executed with the query plan for that row. So, in your case, the procedure could have been executed at 1630 on a previous day (since you didn't show the date) and then 1700 on the current day, or visa versa. Given the repeat-ability of your scenario, your current job is likely using one plan, and another job (even on another day) is using another plan. It's unclear how you are choosing which row to insert... perhaps TOP 1 without an ORDER BY . This could cause this behavior. We'd need to see insert statement that is doing the logging

Note that there are many things that could cause the plan to get removed from cache or a new one created. The latter is less likely in a Job with fixed parameters.

If you really want to track the execution of the procedure (not only the last execution of a cached plan), you'll need to set up a logging mechanism. Aaron has a good article on it her e.