SQL Server错误3930：事务无法提交需回滚，触发器报错根因排查

针对你遇到的问题，结合错误编号3930、生产环境独有且无法复现的特性，从以下角度拆解排查：

1. 错误3930的核心本质 #

这个错误是SQL Server在事务提交阶段抛出的异常，提示事务状态已损坏，无法完成日志写入，必须回滚。它不是触发器内部逻辑（比如字段校验、数据处理）的直接错误，而是事务上下文出现了异常。

2. 为什么日志里显示触发器名称？ #

ERROR_PROCEDURE()函数返回的是触发错误的当前执行模块——也就是说，当错误被触发器的CATCH块捕获时，它会返回触发器名称，但这并不代表错误根源在触发器本身。实际场景可能是：外层操作（比如某个存储过程的显式事务）已经处于异常状态，触发触发器后，事务的错误被触发器的CATCH块捕获，所以日志记录了触发器名称。

3. 可能的根源方向（针对生产环境独有特性） #

• 高并发/批量操作差异：生产环境可能存在大量批量更新或高并发写入，测试环境无此场景。这种情况下，触发器执行会加剧锁竞争、日志文件写入压力，甚至触发事务超时，导致事务状态损坏。比如批量更新时，触发器里的循环操作长时间持有锁，导致事务日志无法及时写入。
• 外层事务的异常上下文：如果调用该表更新的存储过程使用了显式事务，且外层TRY/CATCH块未正确处理异常（比如只捕获错误但未回滚事务），会导致脏事务上下文进入触发器执行阶段，最终触发3930错误。
• 触发器的事务逻辑问题：检查触发器代码是否存在伪嵌套事务（比如使用BEGIN TRANSACTION）——SQL Server不支持真正的嵌套事务，这种写法会导致事务计数混乱，引发提交失败。另外，触发器写入Mas_ErrorLog的操作依赖事务日志，如果日志表所在文件组空间不足、日志文件无法自动增长，也会触发该错误（生产环境日志量远大于测试环境，更容易触发）。
• 数据库配置差异：生产环境可能使用FULL恢复模式，测试环境用SIMPLE模式。FULL模式下日志文件需定期备份，若备份不及时导致日志文件填满，会影响事务提交。

4. 现有日志的局限性优化建议（针对未来排查） #

当前错误日志仅记录触发器层面信息，缺少外层调用上下文。如果后续优化日志，可在INSERT语句中添加：

APP_NAME() AS ApplicationName,
HOST_NAME() AS HostName,
SUSER_SNAME() AS LoginName,
(SELECT text FROM sys.dm_exec_input_buffer(@@SPID, NULL)) AS ExecutedSQL

这样能捕获触发触发器的外层SQL语句或存储过程，更便于定位根源。

内容的提问来源于stack exchange，提问作者Vivek Nuna