SQL Server Isolation levels

Isolation levels in SQL Server control the way locking works between transactions.

SQL Server 2008 R2 supports the following isolation levels:

• Read Uncommitted
• Read Committed (The default)
• Repeatable Read
• Serializable
• Snapshot

Before we go further it is important to understand these two terms as well:

Dirty Reads – This is when you read uncommitted data, when doing this there is no guarantee that data read will ever be committed meaning the data could well be bad.

Phantom Reads – This is when data that you are working with has been changed by another transaction since you first read it in. This means subsequent reads of this data in the same transaction could well be different.

This is the lowest isolation level. There is Read uncommitted causes no shared locks to be requested which allows you to read data that is currently being modified in other transactions. It also allows other transactions to modify data that you are reading.

You can imagine this can cause some unexpected results in a variety of different ways such as data returned by the select could be in a half way state if an update was running in another transaction causing some of your rows to come back with the updated values and some not to.

This is the default isolation level and means selects will only return committed data. Select statements will issue shared lock requests against data you’re querying this causes you to wait if another transaction already has an exclusive lock on that data. Once you have your shared lock any other transactions trying to modify that data will request an exclusive lock and be made to wait until your Read Committed transaction finishes.

This is similar to Read Committed but with the additional guarantee that if you issue the same select twice in a transaction you will get the same results both times. It does this by holding on to the shared locks it obtains on the records it reads until the end of the transaction; this means any transactions that try to modify these records are forced to wait for the read transaction to complete.

This isolation level takes Repeatable Read and adds the guarantee that no new data will be added eradicating the chance of getting Phantom Reads. It does this by placing range locks on the queried data. This causes any other transactions trying to modify or insert data touched on by this transaction to wait until it finished.

This provides the same guarantees as serializable. So what’s the difference? Well it’s more in the way it works using snapshot doesn’t block other queries from inserting or updating the data touched by the snapshot transaction. Instead row versioning is used so when data is changed the old version is kept in tempdb so existing transactions will see the version without the change. When all transactions that started before the changes are complete the previous row version is removed from tempdb. This means that even if another transaction has made changes you will always get the same results as you did the first time in that transaction.

You are not blocking anyone else from modifying the data while you run your transaction but this usage extra resources on the SQL Server to hold multiple versions of your changes.