当执行 CREATE TABLE 或 ALTER TABLE 操作时,sql server 存储什么类型的审计信息?

发布于 2024-07-25 05:40:40 字数 385 浏览 2 评论 0原文

这个问题的灵感是一个存储过程对我造成了影响,因为它调用了另一个存储过程,该存储过程将数据插入到其架构完全改变的表中。

问题是您在 SQL Server 数据库中有一个表,但您不知道它是如何到达那里的。 您没有任何用于自定义审核信息的 DDL 触发器,并且表 DDL 的源代码控制存储库中没有记录。 仅使用 SQL Server,您可以获得有关该表的哪些取证数据。

我自己以及任何在类似情况下偶然发现这个问题的人,都不会从有关版本控制和 DDL 触发器的建议中得到帮助。 这些都是很棒的前进解决方案,如果公司政治允许我们实施这些解决方案,这个博客上有大量关于这些主题的信息。 我和处于我这种情况的人真正需要的是能够从 SQL Server 收集尽可能多的数据片段,以便与我们能想到的任何其他数据相结合。

The inspiration for this question is a stored proc broke on me because it called another stored proc that inserted data in a table whose schema was completely altered.

The question is you have a table in a SQL Server database, and you don't know how it got there. You don't have any DDL triggers in place for custom audit information, and there is no record in your source control repository of the tables DDL. Using only SQL Server, what forensic data can you obtain about the table.

Myself, and whoever stumbles across this question in a similar situation, is not going to be helped by suggestions regarding version control and DDL triggers. Those are great go forward solutions, and there is plenty of info on this blog about those topics, if corporate politics allows us to implement those solutions. What I, and people in my situation really need is to be able to gather as many fragments of data as possible from SQL server, to combine with whatever other data we can come up with.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

記柔刀 2024-08-01 05:40:40

不幸的是,您无法重建所发生的情况,除非:

  • 如果 DBA 有正在运行的跟踪和历史记录。 这些跟踪用于查明崩溃之前发生的情况

  • 如果您有完整恢复模型,那么您可以尝试日志查看器工具(免费 Red Gate one)

  • 根据活动和您的安全模型,您还可以检查 Windows 安全日志以了解谁使用 DDL 权限登录

  • SQL 事件日志也可能有信息。 例如,如果您启用了记录“权限”错误的跟踪标志,那么您可以看到它何时启动。 或者进行更改的人可能生成了记录的其他异常,

  • 您可以询问拥有权限的人。 这可能是一个真正的错误(例如,认为他们在开发中)

Unfortunately, you have no way to reconstruct what happened, except:

  • if the DBAs have traces running and the history. SQL Server 2005 has a default trace and there is the "blackbox" trace, but these are used to find out what happened right before a crash

  • if you have FULL recovery model, then you can try a log viewer tool (free Red Gate one)

  • depending on activity and your security model, you could also check the Windows Security Log to see who logged in with DDL privileges

  • the SQL event logs may also have information. For example, if you have enabled the trace flag that logs "permission" errors, then you can see when it started. Or the person who made the change may have generated other exceptions that are logged

  • you could ask those with rights. It could be a genuine mistake (eg thought they were in dev)

马蹄踏│碎落叶 2024-08-01 05:40:40

以下查询获取了创建时间和上次修改时间。

SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbTableInQuestion]') AND type in (N'U')

The following query got me the create and last modify time.

SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbTableInQuestion]') AND type in (N'U')
塔塔猫 2024-08-01 05:40:40

您应该能够在事务日志中找到表的创建。 我在这里从未使用过任何查看器工具,并且我无法告诉您如何及时搜索,但一切都发生在事务中,因此必须记录下来 - 甚至是系统表。 ..

You should be able to find the creation of the table in the transaction log. I have never used any of the viewer tools here, and I couldn't tell you how to search back in time for this, but everything happens in a transaction, so it's gotta be logged -- even the system tables...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文