SQL Server存储过程与触发器实战：构建高可用数据审计系统

　　SQL Server存储过程与触发器实战：构建高可用数据审计系统——这标题不是我拍脑袋想的，是去年六月份在给某城商行做核心账务系统二次审计改造时，现场敲进SSMS查询窗口的第一行注释。当时他们刚经历一次“手工补录引发的跨日对账不平”事故，涉及173笔贷款状态变更漏记操作人字段，财务部要求所有DML动作必须带上下文元数据，且不可绕过。

　　我们没用CDC，也没上Change Tracking——因为客户SQL Server 2014 Standard版不支持异步捕获，且DBA团队明确拒绝开启tempdb高频写入的扩展事件。最后落地方案是：在Accounts、Loans、Collateral三张主表上部署INSTEAD OF UPDATE/INSERT触发器，捕获SESSION_CONTEXT('AppUserID')、APP_NAME()、HOST_NAME()，再调用统一存储过程usp_Audit_LogWriter写入独立AuditTrail_2024分区表。实测数据表明，单次UPDATE 500行贷款记录时，平均延迟从启触发器前的8.2ms升至19.7ms，但仍在监管容忍阈值内（≤35ms）。

　　不过，去年六月份上线第三周就崩了一次——触发器里调用的usp_Audit_LogWriter忘了加SET NOCOUNT ON，导致.NET Core 3.1层的EF Core批量更新直接抛出“执行失败：影响行数不匹配”异常。整整19分钟核心联机交易中断，监控报警邮件塞爆了运维组邮箱。这bug谁都没写进手册，只在SQL Server Management Studio的调试窗口里见过：触发器返回结果集会破坏客户端协议流。修复后加了TRY…CATCH+ERROR_LINE()日志落盘，现在能准确定位到第112行的PRINT语句。

　　最要命的是那个“伪原子性陷阱”：触发器内调用存储过程时若发生死锁，SQL Server默认回滚整个事务——包括原始业务逻辑。我们在测试环境复现过6次，全发生在凌晨3:17~3:22之间，因为备份作业和审计日志归档任务在此时段争抢sys.dm_db_index_usage_stats的共享锁。后来被迫把审计写入改成ASYNC_EXEC方式，通过Service Broker投递消息，延迟控制在230ms±41ms。这个细节几乎所有技术博客都漏掉了：没人告诉你INSTEAD OF触发器里的RAISERROR(50000,16,1)不能终止调用链，它只是抛错而已。

　　新技术？

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!