生产数据库中的一张表“神秘地”消失了。
有人知道有什么办法可以诊断出这到底是怎么回事吗?是谁干的?
编辑1:这是一个内部应用程序,安全性较弱。所有应用程序(当然除了我的应用程序 ;-) 都容易受到 SQL 注入攻击,但我们的用户非常不复杂,并且表名可能不是立即显而易见的,所以我不认为这是一个 SQL 注入(这并不重要......有点超出了问题的范围)。
编辑2:此外,仅供参考;这个表已经存在很长时间了,因此无法通过恢复来“撤消”它。
答案1
您可能能够使用未记录的 ::fn_dblog 函数从日志中获取信息,该函数可解释日志记录。我现在正在教授灾难恢复课程,但如果您可以等待 2-3 小时,我会发布如何为您做到这一点 - 也应该能够获取用户名,而无需购买任何工具(我曾经在 2000 年大量研究日志,因为我编写了 DBCC CHECKDB 在 2000 年使用的大量内部日志分析代码)。
[编辑以包含说明] 好的 - 教学结束,我写了一篇博客文章,向您展示如何分析 2000、2005、2008 年的日志,以找出表被删除的时间和删除者。查看我的博客文章使用事务日志找出谁删除了表。 [/编辑]
您是否还保留着事务日志?数据库采用哪种恢复模式?如果是 SIMPLE,则不要执行任何会导致检查点的操作。如果是 FULL 或 BULK_LOGGED,则不要进行日志备份。这两种情况都会导致日志被截断,然后您可能无法回顾日志,尽管我在博客文章中包含了一个跟踪标志,可能也会对您有所帮助。
谢谢
PS 在 2000 年防止表删除而不增加安全性的一种方法是在其上创建一个简单的模式绑定视图 - 如果视图存在,DROP TABLE 将失败。
答案2
也许是 Little Bobby Tables......
答案3
您也许能够从 SQL 日志中恢复此信息。
答案4
我正在尝试修复损坏的 MSDB。抱歉,我无法详细说明。
运行这些,它应该会给出一个大致的想法,假设你的默认跟踪是开启的。
从 ::fn_trace_getinfo (默认)中选择 *
选择 t.EventID、t.ColumnID、e.name 作为 Event_Description、c.name 作为 Column_Description 从 ::fn_trace_geteventinfo(1) t 加入 sys.trace_events e ON t.eventID = e.trace_event_id 加入 sys.trace_columns c ON t.columnid = c.trace_column_id