Blocking continues after enabling snapshot isolation

Question

On database hosted on a SQL Server 2012 instance, I have enabled ALLOW_SNAPSHOT_ISOLATION and verified the state as ON using

SELECT snapshot_isolation_state_desc,name from sys.databases

However, in 2 separate sessions, if I run a long running select with TABLOCK in the 1st and an UPDATE in the 2nd (or vice versa), whichever query starts first blocks the second query (as per sp_who2)

Looking at

select * from sys.dm_exec_requests , both queries have a transaction isolation level of read committed (2)

As per my understanding, with snapshot isolation on, tempdb usage should increase however blocking should not occur in this situation. Am I missing some configuration steps to achieve this behaviour?

Answer 1

If your intention is to avoid readers from blocking writers and visa-versa in the default READ_COMMITTED isolation level, turn on the READ_COMMITTED_SNAPSHOT database option. This will cause row versioning instead of locking to be used to implement statement-level read consistency.

Although often confused, the ALLOW_SNAPSHOT_ISOLATION option is not related to READ_COMMITTED_SNAPSHOT. ALLOW_SNAPSHOT_ISOLATION allows the separate SNAPSHOT isolation level to be used to provide multi-statement read consistency but code changes are required to use it. The READ_COMMITTED_SNAPSHOT option provides statement-level read-consistency without code changes, although one should be aware of the implications the locking behavior have on apps that rely upon locking.

Answer 2

Enabling ALLOW_SNAPSHOT_ISOLATION does not alter the behaviour of your code. Instead it lays the groundwork for you to be able to use row versioning if you wish. Once snapshot isolation has been applied to the database a query can succesfully use row versioning if the following statement is used:

SET TRANSACTION ISOLATION LEVEL SNAPSHOT

This post by Kendra Little gives a good introduction to snapshot isolation levels.