SQL Server 2008R2 sys.dm_exec_procedure_stats - 上次执行时间异常

Posted 2023-05-08

【中文标题】SQL Server 2008R2 sys.dm_exec_procedure_stats - 上次执行时间异常

【英文标题】：SQL Server 2008R2 sys.dm_exec_procedure_stats - unusual last execution time

【发布时间】：2018-07-10 10:20:52

【问题描述】：

我有一个从 sys.dm_exec_procedure_stats 捕获数据的工作。 作业每分钟运行一次。它是直接插入，没有连接。 我有一个场景，非常定期（每周两天完全相同）一个特定的对象 id 返回如下所示的内容

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

存储过程由大约 16:30 开始的作业调用 存储过程没有在 17:00 运行（据我所知）。 有一个作业在 17:00 开始但不执行此存储过程。 存储过程大约需要 30 秒才能完成。

object id 都是一样的，database id 也是一样的。

这种情况经常发生而没有失败意味着可能还有另一个过程

我不知道是否有任何事情发生，例如重新启动等 我也不确定是否有可能调用存储过程的外部进程（其他服务器/excel/etc），或者可能存在回滚。

这可能是一个红鲱鱼，我忽略了一些东西，但我已经检查了我能想到的一切。 关于 LastExecutionTimes 的任何想法？

谢谢

【参考方案1】：

对于每个缓存存储过程计划，该DMV包含一行，并且该行的生命周期与存储过程保持缓存状态一样长。这意味着存储过程在此表中可以有 多 行，如果缓存中没有计划，则根本没有。 last_execution_time 对应于上次使用该行的查询计划执行该过程的时间。因此，在您的情况下，该程序可能在前一天的 1630 执行（因为您没有显示日期），然后在当天的 1700 执行，反之亦然。鉴于您的场景的可重复性，您当前的工作可能正在使用一个计划，而另一项工作（即使在另一天）正在使用另一个计划。目前尚不清楚您是如何选择插入哪一行的......也许TOP 1 没有ORDER BY。这可能会导致此行为。我们需要查看执行 logging

的插入语句

请注意，有很多事情可能会导致计划从缓存中删除或创建一个新计划。后者在具有固定参数的作业中不太可能。

如果你真的想跟踪过程的执行（不仅仅是缓存计划的最后一次执行），你需要设置一个日志机制。 Aaron has a good article on it here.

【讨论】：

您好，感谢您的回复。这一切都在同一天。没有其他作业调用此过程。我通过修改写入日志表的过程证明了这一点。另外，如前所述，我没有选择要插入的行。它是直接插入，即 INSERT mytable SELECT * FROM sys.dm_exec_procedure_stats

该过程仍然可以有多个计划。你能检查一下吗？

刚刚检查过，该过程没有其他计划。

INSERT [myCapture] ([database_id] ,[object_id] ,[type] ,[type_desc] ,[sql_handle] ,[plan_handle] ,[cached_time] ,[last_execution_time] ,[execution_count] 等) 从 sys.dm_exec_procedure_stats 中选择 [database_id] ,[object_id] ,[type] ,[type_desc] ,[sql_handle] ,[plan_handle] ,[cached_time] ,[last_execution_time] ,[execution_count] 等

对不起，我无法复制这个。如果计划缓存没有被刷新，我很难相信只有 1 个计划