通常，数据库的数据的都是程序发送的指令进行增删改。后台进行日常维护包括备份、索引重建等工作，当然也存在直接执行update语句以修复错误数据的情况，如果这种行为发生在客户身上，并且客户是个二把刀，那么可能会出后果无人承担的情况。那么除了从制度上明确上述行为之外，技术上能否进行一些追踪呢？

我们可以通过下面语句获取到当前正在执行的语句：

DECLARE @Handle varbinary(64);SELECT @Handle = sql_handle   FROM master..sysprocesses WHERE spid=@@SPIDSELECT * FROM sys.fn_get_sql(@Handle);  GO

就是说知道了连接spid，我们就可以获取到spid当前执行的是哪个语句。这与从“”活动监视器“”里面取进程的命名是一个原理。

回到主题，如果要监控数据变化，我们就得在触发器里面安插自己的监控，从而记录事件发生的时间地点人物，事情的起因经过结果。

那么在触发器里面上面这句是否有效呢，答案是否定的。

下面祭出大招：

CREATE TABLE #inputbuffer(      EventType nvarchar(30),       Parameters smallint,       EventInfo nvarchar(4000)    )insert into #inputbufferexec(‘dbcc INPUTBUFFER( @@SPID )‘)

关键在于这句，获取触发当前spid的语句，返回三个字段。如果是由存储过程触发的，则返回存储过程名

取到原始语句后，我们就可以判断数据变化到底是由那个语句触发，为我们进一步判断罪魁祸首提供依据。

当前了，这种行为都是事后诸葛，而且会损失一部分数据库性能。

如要从根源上有效预防这种情况还是要从制度上去分清楚权利和责任。

在SQLServer里面追寻触发器触发的源头