@H_301_0@　　数据库的一致性，也是衡量DBMS性能的重要指标之一。目前大多数商业数据库(DB2,sql Server)的并发控制采用的是两阶段锁(Two-Phase Locking，2PL)协议，2PL保证了并发事务执行的可串行化。但2PL在对任何数据进行读、写操作之前，需要对该数据加锁。在封锁相容矩阵中，S锁(Share Locks，共享锁)和X锁(Exclusive Locks，排它锁)是不相容的，因此当事务1正对数据A进行读操作(加S锁)时，事务2想要对数据进行写操作(加X锁)，那么事务2必须等待事务1释放数据A上的S锁，才能继续执行。多版本并发控制(Multi-Version Concurrency Control，MVCC)较好地解决了这一问题。在多版本的系统中，每一次写数据均产生一个新的版本，读操作可以根据需要读取合适的版本，因此读写操作互不阻塞。MVCC虽然提高了并发度，但也带来了维护多个版本的存储开销。

@H_301_0@　　Microsoft sql Server 数据库引擎引入了现有事务隔离级别的一种新的实现方式 - 已提交读，用于提供使用行版本控制的语句级快照。sql Server 数据库引擎还引入了一个新的事务隔离级别 - 快照，用于提供也使用行版本控制的事务级快照。

@H_301_0@　　将 READ_COMMITTED_SNAPSHOT 数据库选项设置为 ON 可启用使用行版本控制的已提交读隔离。将 ALLOW_SNAPSHOT_ISOLATION 数据库选项设置为 ON 可启用快照隔离。为数据库启用任一选项时，数据库引擎都将保持被修改的每一行的版本。每当某个事务修改行时，修改前的该行图像将被复制到版本存储区的一页中。版本存储区是 tempdb 中的数据页集合。如果有多个事务修改行，则该行的多个版本将被链接到一个版本链中。使用行版本控制的读操作将检索每一行在事务或语句启动时已提交的最后一个版本。

@H_301_0@　　为 sql Server 2008编写的或 sql Server 中新增的应用程序，通过在 READ_COMMITTED_SNAPSHOT 数据库选项为 ON 时指定读提交的事务隔离级别，来实现使用行版本控制的读提交的隔离。所有读操作都将查看语句启动时已提交的行版本。这将提供数据的语句级快照。

@H_301_0@　　为 sql Server 编写的应用程序将通过在 ALLOW_SNAPSHOT_ISOLATION 数据库选项为 ON 时指定快照事务隔离级别，来实现快照隔离。快照事务中的所有读操作都将查看事务启动时已提交的行版本。这将提供数据的事务级快照。

@H_301_0@　　对于使用基于行版本控制的隔离级别的事务，读操作不对数据请求共享锁。这意味着使用行版本控制的读取器不会妨碍其他读取器或编写器访问同一数据。同理，编写器也不会妨碍读取器。但是，编写器会互相妨碍(即使是在基于行版本控制的隔离级别下运行)。两个写操作不能同时修改同一数据。

@H_301_0@　　“快照隔离”功能扩展了 sql Server 2008 中的锁定框架，它使应用程序能够在发生任何数据修改之前查看值。这可防止应用程序被锁定，同时仍将提供真正已提交的数据。sql Server 2008 的 Read Committed Snapshot 需要数据库管理员来激活,允许数据被只读事务读取。所以 SI 对只读事务的并发控制效果是很好的，但是对更新事务是否也这样不得而知。对长时间运行的更新事务来说更为不利于与短期的高竞争性事务。如果跨数据库的事务试图使用 快照隔离(SI)标准 ，而不是所有数据库都设定的话，则该事务会失败。这无疑给可扩展性带来一定的障碍。看来微软要实现自己的比 sql 92 规范还要强的 SI 还有很多路要走。

@H_301_0@　　参考资料:

@H_301_0@　　锁定和行版本控制: http://technet.microsoft.com/zh-cn/library/ms187101.aspx

@H_301_0@　　分析及解决sqlServer死锁问题：http://www.wfuwu.com/a/view/8307.html

@H_301_0@　　作者: 自由、创新、研究、探索……
　　出处：http://shanyou.cnblogs.com/