When using the Snapshot transaction isolation level, deadlocks are exceedingly rare, but snapshot update conflict errors are common (in a busy OLTP system). These errors are often expected under certain workloads, but if you have something in your application that is creating a large volume of them, how do you go about analyzing the queries causing conflicts and the resources involved in an intuitive (and ideally graphical) way?

Under Serializable or other pessimistic isolation levels, similar scenarios may have caused deadlocks and produced pretty deadlock graphs to help you track down the resources involved in a conflict. Is there any analogous tool for "update conflict" errors, and if not, what is your approach?

1

There are 1 answers

0
SQLpro On

Ansolutly not... Because the deadlock has no logical solution, it is handled by a user logout resulting in a forced ROLLBACK, while the exception related to a transactional update anomaly can be solved logically by an adjustment of your code and in no way constitutes a functional dead end.

The only thing you can do is to trace this exception using the SQL profiler or eXtended Events.