如何find存储过程何时被删除以及谁删除了？

你得到pipe理跟踪：

select * from fn_trace_getinfo(NULL) where property=2 and traceid = 1 

您查看47类事件的pipe理跟踪对象：对象types8727上的已删除事件类 存储过程 ：

 select * from fn_trace_gettable('....trc', -1) where EventClass = 47 and ObjectType=8727 

pipe理跟踪会定期回收并保留大约4-5个跟踪，您应该使用仍然存在的最旧的trc文件的名称。

如果程序非常重要，DBA应该确保只有经过授权的人员才能对其进行修改或删除。 审计模式变化应该已经到位。 这不是谁丢下程序的错，而是完全是DBA的错。

没有办法在默认情况下find这个信息，因为SQL Server不支持这个。 如果数据库处于完全恢复模式，则可以尝试读取事务日志并查看DROP PROCEDURE语句何时执行。 不幸的是，没有简单的方法来做到这一点。

你可以尝试使用一些第三方工具，如ApexSQL日志或Quest的蟾蜍，但即使这些工具，我不知道你将能够找出谁做的这个用户名。

你可以尝试的另一个select是检查fn_dblog函数，看看你是否可以使用它。 这里的问题是这个函数没有很好的logging。

我想你在这里问错了问题。

为什么地球上你不信任的人在数据库中有足够的权限去实际上删除那个sproc呢？ 这是你需要问的问题。

就好像试图找出谁把你的房子钥匙从门廊上拿走后抢劫了你的房子。

假设SQL Server的“平均”默认安装，现在坐在您的服务器上，您将无法确定此信息。 默认情况下，SQL不会logging或跟踪这种活动。

（有很多方法可以logging这些信息（DDL触发器），但是现在不能帮助你 – 这只会有助于未来的活动。）

Chris提到要审查事务日志并提取出现在那里的信息。 这将工作，但SQL 2005不提供任何“原生”function筛选事务日志。 您需要使用第三方工具才能这样做。 只有那些数据在事务日志中才适用。 如果数据库恢复模式设置为“简单”，则该数据将从日志中删除 – 而不是稍后。 （如果您的数据库正在使用，它可能已经不存在了。）

Remus Rusanu概述了如何查询系统跟踪。 非常酷，我是upvoting那一个！ 正如他所说，这也有一个有限的保质期 – 你应该现在复制这些文件，然后才被覆盖。

如果上述策略不可行，恢复和审查备份可能会在发生时进行跟踪。 这又取决于你的恢复模式和你有什么备份文件。 如果您可以对事务日志备份进行时间点恢复，那么您应该能够对丢弃的时间进行相当接近的估计; 如果你只有完整备份或差异备份，则精确度会降低（例如在下午1:00备份，不在下午2:00备份，必须在1到2之间）。

至于谁放弃了（或者说，通过哪个SQLlogin被删除），除非你有一些有意的configuration的进程安装并运行，我不相信你可以提取这些信息。 一个起点是确定谁（而不是login） 可以执行的下降，并从那里去。 您的SQL安装是否configuration为在Windows事件日志中logging成功login？ 域是否设置为跟踪域login？ …虽然如果涉及SQL身份validation都不会有所帮助。

这可能是不可能的，但你也许可以进行一些合理的猜测。 祝你好运！

您应该能够通过事务日志返回，并能够至less了解何时从数据库中删除了该过程。 至于用户是谁，您可能能够看到当时谁已经login到系统，并能够稍微缩小它。

希望这有助于一些。

您可以使用以下脚本来识别可疑用户：

 SELECT te.name AS eventtype ,t.loginname ,t.spid ,t.starttime ,t.objectname ,t.databasename ,t.hostname ,t.ntusername ,t.ntdomainname ,t.clientprocessid ,t.applicationname FROM sys.fn_trace_gettable ( CONVERT (VARCHAR(150) ,( SELECT TOP 1 value FROM sys.fn_trace_getinfo(NULL) WHERE property = 2 )),DEFAULT ) T INNER JOIN sys.trace_events as te ON t.eventclass = te.trace_event_id WHERE eventclass=164