用于用户审计的系统视图触发器的替代方法

Question

即使写标题，我也对我尝试过的想法感到畏缩（但是，嘿，我在这个过程中学到了一些东西）。

我遇到了一个问题，开发人员在数据库上运行迁移脚本并在此过程中覆盖数据库中已经存在的存储过程（DEV，感谢上帝）。

但是，无法找出谁进行了这些更改，因为：

1. 他们不承认
2. SQL Server 不会填充 系统视图中的principal_id列sys.objects，因为每个人都以dbo（此处为更多信息）的身份连接。

所以，我尝试在 sys.objects 上写一个触发器，但没有奏效（我不知道为什么我曾经期望它），因为我收到了一个错误：

对象“DEV_DB.sys.objects”不存在或对于此操作无效。

我还尝试为每个开发人员创建一个用户，这样当他们进行自动迁移时，他们将使用我创建的用户，希望sys.objects该开发人员所做的所有更改都将作为他们登录的用户记录。

但是，这并不能工作，因为principal_id还没有填充（我所做的一切就是为每一个开发者＆DB新的登录/用户，并赋予登录特定服务器角色：public，db_datawriter，db_datareader，db_ddladmin）。

关于我还可以尝试什么作为替代方案的任何建议？

Answer 1

您始终可以点击默认跟踪来捕捉对对象的任何更改，包括存储的过程。

试一试下面的脚本，很容易找出谁在什么时候改变了什么。它帮助我发现了不止一个狡猾的开发人员 ;)

SELECT  t.DatabaseName, t.ObjectID,t.NTUserName,t.HostName,t.StartTime, te.name
FROM ::fn_trace_gettable('C:\Program Files\Microsoft SQL 
Server\MSSQL13.SQL2016\MSSQL\Log\log.trc', DEFAULT) t  
JOIN sys.trace_events te  on t.EventClass = te.trace_event_id  
ORDER BY t.StartTime DESC;

您需要更改 SQL 跟踪文件所在位置的路径，以找出它运行的位置：

select path 
from sys.traces
where id = 1

一个提示，_number从文件名中删除以读取所有可用的跟踪文件，例如，如果文件名是log_16.trc，请将其更改为log.trc.