SnapShot Isolation in SqlServer 2005

Before going into SnapShot Isolation in SqlServer 2005, I thought that it will be better if I explain about
SqlServer 2000 Isolation Levels and Locks. Even today, some who deal with databases don't seem to
have an adept knowledge of this. There are about 4 transaction isolation levels. They are:

1) Read Uncommitted
2) Read Committed
3) Repeatable Read
4) Serializable

Note: These isolation levels affect the way that transactions take and hold shared locks on data
resources. Shared locks are the locks taken when reading data; Exclusive locks are the locks taken
when changing data through an INSERT, UPDATE, or DELETE statement.

Read Uncommitted

Read Uncommitted allows Dirty Read. [Dirty read occurs when your transaction tries to read a data
which is not yet committed or rolled back. For example you are selecting a range of values. lets say ,
the employees names between a range and if an uncommitted transaction is changing the names in
that range and your select statement were to read the changed data, your transaction would be
performing a dirty read.] Here [in Read Uncommitted state] your select statement will not take the
shared locks on the data for reading and so it is not blocked by any transaction that has an exclusive
lock on the data because it is changing it.

You can set the appropriate isolation level for an entire SQL Server session by using the SET
TRANSACTION ISOLATION LEVEL statement. This is the syntax from SQL Server Books Online:

SET TRANSACTION ISOLATION LEVEL

{
READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE
}

Read Committed

Read Committed prevents dirty reads and allows non repeatable reads. This is the default isolation
level of Sql Server 2000 and Sql Server 2005. When you are using Read Committed isolation level the
select statement you issue in a transaction will be using shared locks while reading the data. So at this
point of time your transaction will be temporally blocked because the shared locks are not compatible
with exclusive locks. But SQL Server releases its shared locks on reads after finishing the SELECT
statement, so other transactions may change the data. So you are not guaranteed to see the same data
at any time in the transaction. Imagine that your transaction has two select statements, one at the
beginning (which retrieved 1000 records) and another one at the end, which may have retrieved a
different number of rows. This is because the shared lock gets removed after the first select statement
which opened the door for an update or delete statement and we may have a different number of
results or records in the last select statement which explains that it allows non repeatable reads.

Repeatable Read

SQL Server accomplishes the REPEATABLE READ isolation level by holding all shared locks that your
transaction acquires until the end of your transaction. But it does not prevent phantoms. Phantoms
are nothing but new rows that may be inserted into the range. For example you issue a select
command which fetched you 1000 rows and later you got 1001 rows because a new row is inserted.
Your transaction is still not completely isolated.

Serializable

Serializable is the strongest type of isolation level .It doesn't allows Phantom values. The SERIALIZABLE
isolation level guarantees that at any other time during your transaction, the same SELECT statement
will result in exactly the same set of 1,000 rows, and they will be unchanged. It prevents other users
from updating or inserting rows into the data set until the transaction will be completed.

Lock Types

There are mainly 3 types of Locks.

1) Shared Locks
2) Update Locks
3) Exclusive Locks

As I explicated above Shared Locks are locks taken when reading data. Shared locks are compatible
with other Shared locks or Update locks .Update Locks are locks happens when there is already a
shared lock on page and sql server wants to set an Exclusive lock (Update Statement ) .Here Update
Lock will be set. Update locks are compatible with Shared locks only. Exclusive Lock is used for the
data modification operations, such as UPDATE, INSERT, or DELETE. Exclusive locks are not compatible
with other lock types.

In my Previous blog I had explained about SqlServer 2000 Isolation Levels and Locks. SQL Server 2005
gives us a new isolation level, SNAPSHOT, resulting in a total of five isolation levels available for
transactions. When the SNAPSHOT isolation level is enabled, each time a row is updated, the SQL
Server Database Engine stores a copy of the original row in tempdb, and add a transaction sequence
number to the row.

How to enable SnapShot Isolation in SqlServer 2005

ALTER DATABASE MyDatabase SET ALLOW_SNAPSHOT_ISOLATION ON

Or

ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON

 The following statements activate snapshot isolation and replace the default READ COMMITTED
behavior with SNAPSHOT. If you enable allow_snapshot_isolation each transaction can decide whether
it wants to enable the Snapshot Isolation feature. If you set read_commited_snapshot then snapshot
isolation is enabled for all transactions automatically. If read_commited_snapshot is off then we have
to set the Snapshot isolation level for each session in order to access versioned rows. You can do this
by issuing this command

Set transaction isolation level snapshot

Eg: USE PUBS SET TRANSACTION ISOLATION LEVEL SNAPSHOT

BEGIN TRANSACTION
UPDATE authors SET phone = '111 111-0000' WHERE au_id = '172-32-1176'

How it Works

When the snapshot isolation is enabled, updated row versions for each transaction are recorded in
tempdb. For a particular transaction there will be a unique transaction sequence number and these
unique numbers are recorded for each row version. A particular transaction (say transaction 2) works
with the most recent row versions having a sequence number before the sequence number of the
transaction (so it will take row versions of transaction 1). Newer versions of row created (by
transaction 2 or transaction 3) are ignored by this (transaction 2). This means that all queries in
transaction 2 will see the same version or snapshot of the database. No locks are acquired on the
underlying data rows or data pages in a snapshot transaction.

Hope this article was useful for you. If you have any more insights or ideas with respect to SnapShot
isolation, please drop in a line so we all can benifit.