SQL Server 2014快照隔离级别错误3960：每日清理存储过程更新冲突求助

遇到这个3960错误我太熟悉了——你的每日清理存储过程用了快照隔离级别，当它尝试更新或删除dbo.SXAVWFInboundEventQueue表的行时，发现这些行已经被其他并发事务修改或者删掉了。快照隔离依赖行版本控制，一旦事务启动后行的版本发生变化，就会触发这个冲突中止的报错。下面给你几个实用的解决思路：

1. 给事务加重试逻辑 #

这类并发冲突大多是偶发的，最简单的办法就是让存储过程自动重试几次。我通常会给这类定时任务加个3-5次的重试机制，配合短暂等待，大概率能解决问题。
示例代码：

DECLARE @RetryCount INT = 0;
DECLARE @MaxRetries INT = 3; -- 可以根据实际情况调整

WHILE @RetryCount < @MaxRetries
BEGIN
    BEGIN TRY
        BEGIN TRANSACTION;
        -- 这里放你的清理逻辑，比如：
        -- DELETE FROM dbo.SXAVWFInboundEventQueue WHERE CreatedDate < DATEADD(day, -7, GETDATE());
        COMMIT TRANSACTION;
        BREAK; -- 成功执行就退出循环
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0
            ROLLBACK TRANSACTION;
        
        -- 只针对3960错误重试，其他错误直接抛出
        IF ERROR_NUMBER() = 3960
        BEGIN
            SET @RetryCount += 1;
            WAITFOR DELAY '00:00:01'; -- 等待1秒再重试，避免瞬间重复冲突
        END
        ELSE
        BEGIN
            THROW; -- 非目标错误直接抛出来方便排查
        END
    END CATCH
END

2. 针对清理操作调整隔离级别 #

如果重试还是频繁失败，或者你想从根源避免这类冲突，可以给清理语句单独设置更适合的隔离级别。比如改用READ COMMITTED（这是默认隔离级别），它会用锁来控制并发，虽然可能有短暂阻塞，但不会因为行版本冲突报错。
示例：

-- 临时切换隔离级别到READ COMMITTED
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 执行你的清理操作
DELETE FROM dbo.SXAVWFInboundEventQueue WHERE <你的过滤条件>;

-- 如果需要恢复原来的快照隔离级别
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

如果你数据库已经开启了READ_COMMITTED_SNAPSHOT，也可以用这个级别，它兼顾了行版本和锁的优点，冲突概率也会低很多。

3. 优化清理逻辑的并发友好性 #

有时候冲突是因为一次性处理的数据量太大，和其他事务的冲突窗口太长。可以试试这两个优化点：

• 分批次清理：不要一次性删除几百上千行，每次删一小批，比如1000行，循环直到清理完成。这样每次操作的时间短，冲突概率会大幅降低。
  示例分批次删除：

  DECLARE @BatchSize INT = 1000;
  WHILE EXISTS (SELECT 1 FROM dbo.SXAVWFInboundEventQueue WHERE <你的过滤条件>)
  BEGIN
      DELETE TOP (@BatchSize) FROM dbo.SXAVWFInboundEventQueue WHERE <你的过滤条件>;
      WAITFOR DELAY '00:00:00.100'; -- 短暂等待，给其他事务留处理时间
  END
  

• 调整清理时间：看看你的清理任务是不是和业务高峰期撞了？如果其他事务在白天频繁操作这个表，把清理改到凌晨低峰时段运行，冲突概率会直接下降。

额外排查小技巧 #

• 先确认你的数据库是否正确开启了ALLOW_SNAPSHOT_ISOLATION和READ_COMMITTED_SNAPSHOT（如果要用的话），可以用SELECT name, snapshot_isolation_state, is_read_committed_snapshot_on FROM sys.databases WHERE name = 'PROD';查询。
• 监控一下其他访问dbo.SXAVWFInboundEventQueue的事务，有没有长时间运行的事务占着行版本，或者频繁更新同一批行的情况——这些都是冲突高发的诱因。

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