无论如何，有没有确定谁丢了桌子？

生产数据库中的表已“神秘地”消失了。

有人知道诊断出到底发生了什么吗？和谁做的？

编辑1：这是一个内部应用程序，安全性较弱。所有的应用程序（当然是我的；-除外）都容易受到SQL注入的攻击，但是我们的用户非常老练，并且表名并不是一个立即显而易见的名称，因此我不认为这是SQL注入（不是这很重要……超出了问题的范围）。

编辑2：另外，仅供参考；该表已经存在很长时间了，因此并没有“恢复”。

您可能可以使用未解释的:: fn_dblog函数来解释日志记录，从而从日志中获取信息。我现在正在上一堂灾难恢复课，但是如果您可以等待2-3个小时，我会为您发布操作方法-应该也可以获取用户名，而无需购买任何工具（ 2000年，我编写了许多内部日志分析代码，DBCC CHECKDB在2000年使用了该代码，那时我常常在日志周围乱写一遍。

[编辑以包括说明]好-完成教学，我打开了一个博客文章，向您展示如何分析2000、2005和2008年的日志，以了解何时删除了该表以及是谁创建的。查阅我的博客文章，查找使用事务日志删除表的人员。[/编辑]

您还有交易记录吗？数据库处于哪种恢复模式？如果它很简单，请不要执行任何会导致检查点的操作。如果是FULL或BULK_LOGGED，请不要进行日志备份。这两种方法都会导致日志被截断，然后您可能会失去回溯日志的能力，尽管我在博客文章中添加了跟踪标志，这也可能对您有所帮助。

谢谢

PS在2000年防止表掉落而不增加安全性的一种方法是在其上创建一个简单的架构绑定视图-如果该视图存在，则DROP TABLE将失败。

也许是小鲍比桌子...

您也许可以从SQL日志中恢复此信息。

如果默认跟踪日志正在运行，则所有信息都存储在日志文件夹中。您应该能够看到何时删除了对象（表）以及通过哪个连接进行了操作。但是无论如何，这种类型的许可应仅授予DBA。

我正在尝试修复损坏的MSDB。对不起，我无法解释。

运行这些命令，并假定您的默认跟踪处于打开状态，应该可以大致了解该查找的位置。

选择* FROM :: fn_trace_getinfo（默认）

选择t.EventID，t.ColumnID，e.name作为Event_Description，c.name作为Column_Description FROM :: fn_trace_geteventinfo（1）t JOIN sys.trace_events e ON t.eventID = e.trace_event_id JOIN sys.trace_columns c ON t.columnid = c.trace_column_id

找出此信息的唯一方法是通过读取事务日志（假定它处于完全恢复模式）。

有两种方法可以做到这一点：

• 第三方工具，例如ApexSQL Log或SQL Log Rescue（免费，但仅适用于sql 2000）
• 使用诸如DBCC LOG或fn_dblog之类的命令–不幸的是，没有一个文档有据可查

在SSMS中，您可以尝试右键单击dB并浏览Reports-> Standard Reports-> Schema Changes History。

右键单击该报告，然后单击“ SaveAs” Excel，然后找到您的对象名称。

如果在删除对象后重新启动服务器超过五次，则将无法获得任何信息。