Sql 如何强制3960的快照隔离失败

故事

我有一个存储过程，使用快照隔离通过合并执行多个插入。此存储过程是以非常高的负载调用的，通常是并行调用的，因此它偶尔会抛出一个错误3960，这表示快照由于更改冲突而回滚。这是预期的，因为高并发性

问题

我已经实现了一个“重试”队列，以便稍后再次执行此工作，但我很难再现错误以验证我的检查是否准确

问题

我如何再现快照故障（特别是3960），以验证重试逻辑是否正常工作

已尝试过

• RAISEERROR不起作用，因为它不允许我提出现有错误，只允许提出用户定义的错误
• 我尝试重新插入相同的记录，但这不会引发相同的失败，因为这不是两个不同的事务“竞争”另一个
为什么不这样做：

RAISERROR(3960, {sev}, {state})

将{sev}和{state}替换为在生产中发生错误时看到的实际值？
（不，正如马丁指出的那样，这是行不通的。）

---

---

如果不是这样，那么我建议尝试同时运行多次测试查询。我自己这样做是为了模拟其他并发错误。只要测试查询不是太快（至少几秒钟），它应该是可行的。
打开两个连接，在两个连接上启动快照事务，在连接1上更新记录，在连接2上更新相同的记录（在后台，因为它会阻塞），然后在连接1上提交

---

或者将用户错误视为3960…
如果您已经独立于实际错误捕获测试了各个部分，则只需使用代码即可。如果你的新代码失败并错过了错误，它不会比现在失败时更糟糕。嗯，你说得对。我想我以前从没试过。。。无论如何，另一种方法应该可以工作（如果测试查询不是太快）。这是我以前做过的。谢谢你的回复！我确实花了时间试图在没有任何运气的情况下重新创造比赛条件。最终，团队决定该代码得到足够的日志支持，因此批准部署live。