查找 <n> 天內未呼叫的過程

我們正在刪除舊的儲存過程和表。

我如何知道最近沒有呼叫哪些程序？

dm_exec_procedure_stats並且dm_exec_query_stats不可靠，因為它們只返回計劃記憶體中的過程。

如果sys.dm_exec_procedure_stats對您不可靠（可能更多是因為資訊在重新啟動後無法存活，而不是與計劃記憶體有關），SQL Server 不會以任何其他方式跟踪這一點。

做到這一點的唯一方法是將日誌記錄添加到您的儲存過程（或呼叫它們的應用程序，如果這可行且足夠包容），或者永久執行非常有針對性的伺服器端跟踪並查看跟踪。

另請注意，僅僅因為一個程序在一周內沒有被呼叫並不意味著它明天不會被呼叫。您可以擁有僅每月或每年呼叫一次的報告程序，或者一些不經常發生的晦澀操作。刪除該儲存過程可能會在幾天或幾週後造成災難性的後果，可能超出您當時擁有的任何備份（假設您沒有遵循最佳實踐並將儲存過程儲存在原始碼管理中）。

恕我直言，最安全的方法是重命名您已經通過其他方式辨識為“太舊”的潛在候選者的儲存過程（可能帶有zzz_前綴，以便它們排序到任何列表的底部） - 然後至少當你無意中對其中一個進行此操作並且出現故障，再次重命名它很容易，恢復功能而無需在備份中尋找舊程式碼。只有在一個完整的商業周期過去並且沒有人抱怨時才刪除程序。

如果您可以修改程序，請在每個程序的開頭添加一行（這很容易自動化）：

exec sp_trace_generateevent 82, N'<procedure__name>';

使用sp_trace_generateevent是相當良性的，不會影響程序執行流程/結果/結果。最重要的是，它與目前事務沒有互動。它不會將只讀過程轉變為數據寫入過程，具有所有日誌記錄和鎖定含義。如果沒有跟踪監視事件 82，則該exec呼叫基本上是免費的（無操作）。

接下來創建伺服器端跟踪並擷取事件 82（第一個 user_event）。n 天后收集生成的跟踪並彙總使用情況。確保您的跟踪寫入具有足夠空間和足夠 IO 頻寬的磁碟。對於額外的信用，您還可以定期檢查跟踪並exec從您在那裡找到的任何程序中刪除呼叫，因為已證明被呼叫。

引用自：https://dba.stackexchange.com/questions/43875