查找在<n>天没有被调用的过程

Question

我们正在删除旧的存储过程和表。

我怎么知道最近没有叫什么程序？

dm_exec_procedure_stats和dm_exec_query_stats不可靠，因为它们只返回计划缓存中的过程。

Answer 1

如果sys.dm_exec_procedure_stats对您来说不可靠(可能更多是因为这些信息无法重新启动，而不是与计划缓存有关)，Server将不会以任何其他方式跟踪这一点。

要做到这一点，唯一的方法是将日志记录添加到您的存储过程中(或者添加到调用它们的应用程序中，如果这是可行且足够包容的话)，或者永远运行一个目标非常明确的服务器端跟踪并检查跟踪。

还要注意的是，仅仅因为一周内没有调用一个过程并不意味着它明天就不会被调用。您可以拥有仅被称为每月或每年的报告过程，或者一些不经常发生的模糊操作。删除该存储过程可能是灾难性的几天或几周后，可能超出您当时的任何备份(假设您没有遵循最佳实践并将存储过程存储在源代码管理中)。

IMHO最安全的方法是重命名存储过程(可能使用zzz_前缀，以便将其排序到任何列表的底部)，这些存储过程已经通过其他方法确定为“太老”的潜在候选者--然后，至少当您无意中对其中一个存储过程进行重命名并出现故障时，就可以轻松地重新命名它，恢复功能，而不必在备份中搜索旧代码。只有当整个商业周期已经过去，没有人抱怨时，才会删除程序。

Answer 2

如果您可以修改这些过程，那么在每个过程的开头添加一行(这非常容易自动化)：

exec sp_trace_generateevent 82, N'<procedure__name>';

使用sp_trace_generateevent是相当良性的，并且不影响过程执行流程/结果/结果。最重要的是，它与当前事务没有交互。它不会将只读过程转换为数据写入过程，包含所有的日志记录和锁定含义。如果没有跟踪监视事件82，则exec调用基本上是免费的( no -op)。

接下来创建服务器端跟踪和捕获事件82 (第一个user_event)。N天后，收集生成的跟踪并汇总使用情况。确保您的跟踪写入具有足够空间和足够IO带的磁盘。为了获得额外的信用，您还可以定期检查跟踪，并从您在那里找到的任何过程中删除exec调用，因为这是被证明是被调用的。

Answer 3

了解最近被调用的内容只会对频繁调用的事物有所帮助，而复杂数据库中的许多对象通常不会被调用，但仍然是必需的。我不知道什么是不被使用的简单方法。

我要做的是在我的dev或qa框上启动Profiler，然后取出每个点击它的应用程序并运行它的功能。(如果您有正式的QA，那么一组良好的回归测试将有助于这一点)。我会设置我的跟踪写到一张桌子上。现在，至少您知道应用程序调用的过程是什么，并且可以从列表中删除它们。

确保prod服务器上的每个作业在您的测试服务器上都有一个相同的作业，并运行它们。应该能找到更多。

到目前为止，您的潜在sps列表要小得多。

您的活动表列表应该只包括在您知道需要的过程和表中提到的那些，比如审计表。YoOu可以创建一个潜在的列表，以消除从那里。

现在，一旦您有了要消除的潜力列表，您可能会看到一些比较明显的潜力，比如usp_my_proc_Old (当您在db中有一个USP_My_proc时)。这些是我第一次淘汰的候选人。此时，没有数据的表是另一组明显的表。明确引用您知道已被删除的功能的表/proc将是下一个。假设最近用新的设计替换了存储调查结果的功能。您可能希望保留该表(您可能需要数据)，但是调用该表的进程可能都已过时，可以离开。

根据您的法律约束，您可能不希望删除任何包含数据的表。我们为我们不再拥有的客户提供了具体的客户数据，因为我们处在一个受监管的行业，偶尔会被要求向审计师、监管机构和律师提供数据。但是，如果要清除实际生产数据库，可以将这些表移动到另一个归档db。

那就开始看看他们是怎么做的。您可以消除任何不能运行的proc，特别是如果它引用的一个表不再存在的话。如果表中有日期字段，那么是否有最近的日期？如果最后一次使用日期填充数据字段是2008年，那么对于我们不再需要的表来说，这是一个很好的候选者。

一旦您有了要删除的几个潜在对象的列表，然后将列表发送给所有开发人员，并询问他们是否使用了表/proc，或者知道它是用于什么目的。不要用一个庞大的1000 s对象列表来做这件事。一次发送不超过10-20，并尝试分组，使他们清楚地在相关的主题。

对于要消除的潜能，您可以向proc添加一个日志进程，或者向表中添加一个日志触发器，并在该日期之前没有条目的情况下，设置对象将被消除的日期。