Understanding Snapshot Isolation
Snapshot isolation consists of these components:

Snapshot isolation framework
Instructs Microsoft® SQL Server™ "Yukon" Beta 1 to keep versions of incoming updates.

Snapshot transaction isolation level
Allows individual applications to execute snapshot isolation queries.

The framework for snapshot isolation must be established for each database before applications can execute snapshot queries. To access data in the database using snapshot queries, the snapshot isolation level for the connection must be set to SNAPSHOT for each application before the application initiates snapshot isolation transactions (transactions execute snapshot queries when reading the data). For more information, see Using Snapshot Isolation.

When the snapshot isolation framework is established, any new update causes SQL Server to store in tempdb a logical copy (or version) of the previously committed value. SQL Server maintains a snapshot of all database changes at the time when snapshot isolation starts. All the versions of a record are marked with a timestamp of the transactions that made the change. The versions of updated records are chained using a link list and stored in tempdb. The newest record value is stored in a database page and linked to the version store in tempdb.

When a user in a snapshot isolation transaction reads the data, SQL Server first accesses the last committed record, and then retrieves the record value from the version store by traversing the chain of pointers to the specific record version of the data.

Disk space of 14-bytes is required for each record being updated for a particular database with the snapshot isolation framework enabled. These 14 bytes are added once for each record during the initial update, and are used to maintain record version information of the most current record stored in the database.

It is recommended that enough disk space be allocated to accommodate this requirement. When there is not enough space available on the current index or data page under snapshot isolation, the process of maintaining record version information with the most current record can cause index-page splits or the allocation of a new data page. SQL Server automatically reclaims the 14-byte space with the first update executed after the snapshot isolation framework is turned off.

Storage in tempdb
Establishing the snapshot isolation framework causes all update records for a particular database to be versioned and stored in tempdb, regardless of whether any users are currently trying to read the data using snapshot isolation scans. SQL Server maintains these records and dynamically claims or releases the disk space for unused versions.

Database administrators must plan ahead and allocate adequate space in tempdb. The following formula provides an approximate value for the version store space allocation in tempdb:

Total version store (KB) = Version generation rate (KB/sec.)* the longest transaction time (sec.)
The version store generation and the longest transaction time can be obtained using SQL Server performance counters available for snapshot isolation.

Data Availability to Readers
The presence of record versions of data in tempdb increases the availability of and concurrent access to the data for users.

The following snapshot isolation properties increase the availability of data:

Read operations with a transactionally consistent snapshot of the database.
Users do not lock data during a read operation (readers do not block writers).
Users can access the last committed value of the row while other transactions are updating the row.
Writers do not block readers and vice versa.
Reduces the number of deadlocks for SQL Server.
Snapshot Isolation Scenario
For example, User 1 is modifying data when User 2 tries to read the same data, both in a snapshot isolation transaction. User 2 is not blocked from reading the data. Although the data is currently locked for updates by User 1, a previous version of the data is available to User 2.

When User 1 commits the updates to the data, future reads of the data executed from a new snapshot isolation transaction will access the updated data.

If User 2 updates the data, SQL Server checks if the data has changed since the start of User 2's transaction. If it has changed, SQL Server rolls back the update transaction of User 2 and returns an error. However, if the data has not changed, SQL Server applies the updates by User 2. Future reads of the data inside the same transaction will show the updates of User 2.

Illustration of Snapshot Isolation Scenario
The following example shows how row versioning works.

User 1: Reader User 2: Writer
USE AdventureWorks
GO
/*Enable snapshot isolation on the database.*/
ALTER DATABASE AdventureWorks
SET ALLOW_SNAPSHOT_ISOLATION ON
CREATE TABLE AWTable (C1 int PRIMARY KEY, C2 int)
INSERT AWTable VALUES (1, 5)


/*Start a snapshot transaction on connection 1.*/
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
SELECT C2 FROM AWTable WHERE C1=1
/*Here is the result set: 5*/

/*Start a new transaction on connection 2.*/
USE AdventureWorks
GO
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
SELECT C2 FROM AWTable WHERE C1=1
/*Here is the result set: 5*/


UPDATE AWTable SET C2=6 WHERE C1=1
SELECT C2 FROM AWTable WHERE C1=1
/*SQL Server is supposed to return 6.*/


/*Return to connection 1 and read AWTable row 1.*/
SELECT C2 FROM AWTable WHERE C1=1
/*Reader is able to read data despite the update transaction in connection 2. Here is the result set: 5*/


/*Commit the update on Connection 2.*/
COMMIT


SELECT C2 FROM AWTable WHERE C1=1
/*SQL Server now returns 6, the updated committed value.*/



Benefits and Costs of Row Versioning
Row versioning in snapshot isolation transactions are most useful in avoiding reader-reader, reader-writer, and writer-reader blocking scenarios and in reducing the number of potential deadlocks. Use snapshot isolation primarily for read transactions or when an occasional transaction rollback due to mandatory conflict detection is not a major issue.

Benefits of Snapshot Isolation Transactions
The benefits include:

Nonblocking consistent reporting and ad hoc queries running parallel with an OLTP application.
Application migration to SQL Server from other relational database systems supporting nonblocking reads.
Consistency of aggregates, such as AVG, COUNT, and SUM, as well as index intersections and index joins without escalating read scans to a higher isolation level.
Deadlock reduction.
Costs of Snapshot Isolation Transactions
The following costs associated with enabling snapshot isolation transactions should be considered when you decide to use row versioning:

When snapshot isolation framework is enabled, update transactions for a particular database must maintain record versions, even if there are currently no readers.
Enough disk space for the version store must be provided. Versions are stored in tempdb. If there are very long-running transactions, all the versions generated by update transactions during the time must be kept in tempdb. If tempdb runs out of space, update operations do not fail, but the snapshot isolation queries might fail.
The overhead of 14 bytes per record must be set aside.
Update performance can be slower due to the work involved in maintaining older versions. The actual difference in the system throughput with the snapshot isolation framework set to ON depends on what percentage of the system resource is spent on updates for the workload. For OLTP workloads where each update changes just a few rows in a database, the performance degradation for database updates is within a few percents compared to nonversioned databases with the snapshot isolation framework turned off. If a very large amount of data is changed in each update, the performance degradation could be higher compared to nonversioned databases.
Data readers face the extra cost of traversing the version link list. Constructing a snapshot of data involves system resources (CPU and memory). The older the snapshot, the slower the process of accessing it in a snapshot isolation transaction. Since the record versions are stored in tempdb, the more tempdb pages can be stored in memory during snapshot version construction, the better is the performance and the lower is the number of issued I/Os.
Some update transactions using snapshot isolation might have to be rolled back because of mandatory conflict detection for update operations.
Limitations of Snapshot Isolation Transactions
Consider the following limitations when working with snapshot isolation transactions:

Distributed transactions, including queries in distributed partitioned databases, are not supported.
If applications use Global temp tables, you must allow snapshot isolation in tempdb. Global temp tables are stored in tempdb.
Snapshot transactions fail when:
A database is made read-only after the snapshot transaction starts, but before the snapshot transaction accesses the database.
The database state was changed in such a way that database recovery occurred after a snapshot transaction starts, but before the snapshot transaction accesses the database. Some examples of this situation include: the database was set to OFFLINE and then to ONLINE, database auto-close and open, database detach and attach.
The following data definition language (DDL) statements are executed inside snapshot isolation transaction:
ALTER INDEX

ALTER PARTITION FUNCTION

ALTER TABLE

CREATE INDEX

CREATE XML INDEX

DBCC DBREINDEX

DROP INDEX

SQL Server does not keep multiple versions of the system meta data. Data definition language (DDL) statements on tables and other database objects (indexes, views, data types, stored procedures, and common language runtime functions) cause subsequent snapshot isolation queries on those objects to fail if the DDL happened after the snapshot isolation transaction started.
This example illustrates what happens in a snapshot isolation transaction when a DDL takes place in another transaction.

User 1: Reader User 2: DDL statement (ALTER INDEX REBUILD)
Use AdventureWorks
GO
/*Enable snapshot isolation on the database.*/
ALTER DATABASE AdventureWorks
SET ALLOW_SNAPSHOT_ISOLATION ON
CREATE TABLE AWTable (C1 int, C2 int)
CREATE INDEX AWIndex on AWTable (C1)
INSERT AWTable VALUES (1, 5)



/*Start a snapshot transaction on connection 1.*/
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
SELECT C2
FROM AWTable
WHERE C1=1
/*Here is the result set: 5*/


/*Start a new transaction on connection 2.*/
USE AdventureWorks
GO


ALTER INDEX AWIndex ON AWTable REBUILD

SELECT C2 FROM AWTable WHERE C1=1
/*SQL Server "Yukon" Beta 1 fails this transaction because a DDL statement on this table was executed (by User 2).*/