http://edu.codepub.com/2009/0921/15553.php
总得来说，READ_COMMITTED_SNAPSHOT可能比较适合于原有数据库设计得相对复杂，不想做太多更改的情况下。它不需要去修改以前的存储过程。这其实是READ_COMMITTED隔离级别的一个改良版本。
而另外一个SNAPSHOT则是一个全新的隔离级别。
下面是我用第二种方式的一个例子
--创建演示用的数据库
create database SnapshotIsolationDemo
go
use SnapshotIsolationDemo
alter database SnapshotIsolationDemo set allow_snapshot_isolation on
create table test
( tid int not null primary key,
tname varchar(50) not null
)
insert into test values(1,'version1')
insert into test values(2,'version2')
--建一个查询，这里故意不提交事务
use SnapshotIsolationDemo
begin tran
update test set tname='version3' where tid=2
select * from test
--再建一个查询，模拟另外一个用户来访问
use SnapshotIsolationDemo
set transaction isolation level snapshot
select * from test
--清理工作
use master
drop database SnapshotIsolationDemo
go
http://www.cnblogs.com/fanweixiao/archive/2008/06/10/1216612.html
1、已提交读快照隔离(RCSI)，通过修改数据库的一个选项来启用
alter database AdventureWorks set READ_COMMITTED_SNAPSHOT on
2、快照隔离(SI),必须在两个地方开启
A、启用数据库的ALLOW_ISOLATION_SNAPSHOT选项
alter database AdventureWorks set ALLOW_SNAPSHOT_ISOLATION on
B、通过set transaction isolation level 命令为每个想要使用SI的连接设置隔离级别
set transaction isolation level snapshot
观察数据库的状态
目录视图sys.databases包含了几个报告数据库快照隔离状态的字段.
snapshot_isolation_state字段的可能值是0到4,表示四种可能的SI状态,而snapshot_isolation_state_desc字段对每种状态作了清晰的说明：
off:数据库关闭了快照隔离状态
in_transition_to_on:数据库正处于开启SI的中间状态
on:SI被开启
in_transition_to_off:数据库正处于关闭SI的中间状态而不能启动新的快照事务
数据库选项read_committed_snapshot可能的状态值
0:关闭
1:开启
并发模型的选择
悲观并发控制时Sql Server2005中的默认设置，也是所有早期版本的唯一选择。事务的行为是由加锁来保证的，而付出的代价是产生较多的阻塞。在访问同一数据资源时，读者和写者之间会互相阻塞。由于Sql Server最初是为使用悲观并发而设计的，用户应该在证明乐观并发确实对应用程序更有用的前提下才考虑使用
在大多数情况下，基于下列原因RCSI比SI更受欢迎：
1、RCSI比SI占用更少的tempdb空间
2、RCSI支持分布式事务,而SI不支持
3、RCSI不会产生更新冲突
4、RCSI无需再应用程序端作任何修改。唯一要更改的只是一个数据库选项
可以考虑在下列情况中使用SI：
1、不太可能由于更新冲突而导致事务必须回滚得情况
2、需要基于运行时间长、能保证时间点一致性的多语句来生成报表的情况
乐观并发控制的优缺点：
优点：
1、select 操作无需获取共享锁，因此读者和写者之间不会互相阻塞
2、所有的select会得到一个始终如一的数据快照
3、与悲观并发相比，锁的需求总量大大减少了,因而将节约更多系统开销
4、Sql Server会执行较少的锁升级
5、发生死锁的可能性较小
缺点：
1、当需要扫描一个很长的版本链时,select语句的性能会有所下降
2、行版本控制需要tempdb数据库中的额外数据
3、只要数据库启用了基于快照隔离级别的某一种时，更新和删除操作都必须产生行版本
4、需要为每个受到影响的行增加大小为14个字节的行版本控制信息
5、更新操作的性能可能会因为维护行版本而变差
6、使用SI模式的更新操作可能会因为冲突检测而被回滚
7、必须小心地控制tempdb的空间