That brings us to Read Committed, which is the default isolation level in SQL Server, except in Azure SQL DB. While it is tempting to use the Read Uncommitted isolation level to avoid some common blocking and deadlocking scenarios, that isolation level comes with a steep price: your queries are subject to every kind of dirty read imaginable.īy the time you realize that your queries have produced bad data, it’s far too late. I’ll talk about why as we go through things a bit here. Note that I’m not including Repeatable Read, Serializable, or Snapshot Isolation. To make the differences clear, here’s how things shake out across a few of SQL Server’s isolation levels I see most commonly. In the most unfortunate of circumstances, optimistic isolation levels are bundled in with Read Uncommitted/NOLOCK as being able to read dirty data. There seems to be quite a bit of misconception about isolation levels, particularly optimistic ones in SQL Server. I spend a lot of time talking about this with clients, because so many of them face dire blocking and deadlocking issues across a variety of queries under the Read Committed isolation level, that can be easily solved by switching to Read Committed Snapshot Isolation.
0 kommentar(er)
