SQL Server 2005 中提供的隔离级别

SQL Server 2005 中提供的隔离级别

隔离级别 脏读(可能的情况) 非可重复读取(可能的情况) Phantom(可能的情况) 并发控制

读取未提交

(无)

读取已提交

 

悲观

读取已提交快照

乐观

可重复读取

悲观

快照

Optimistic

可序列化

悲观

上述每种情况下使用的应用程序根据希望级别的“正确性”和在性能和管理性开销上的平衡选择而有所不同。

隔离级别和应用程序最合适

隔离级别 在以下情况下最适合于应用程序:

读取未提交

应用程序不要求数据的绝对精度(可能得到大于/小于最终值的数值),并且相对于所有其他要求来说更看重 OLTP 操作的性能。不要求版本存储,不要求锁定,没有被授权任何锁定。这种隔离中查询的数据精确度可以看到未提交的更改。

读取已提交

应用程序不要求长期运行集合或长期运行查询的时点一致,但要求被读取的数据是事务一致的。应用程序不希望用版本存储的开销来平衡长期运行查询的可能的不正确,因为没有可重复读取。

读取已提交快照

应用程序要求长期运行集合和/或长期运行查询的绝对的时点一致性。所有数值在查询开始时必须是事务一致的。数据库管理员选择应用程序的版本存储开销,以便获得由于锁定争用减少而带来的吞吐量增加的好处。此外,应用程序需要大型查询(而不是事务)的事务一致性。

可重复读取

应用程序要求长期运行多语句事务的绝对精确度,并且在事务完成之前必须保留来自其他修改的所有请求数据。应用程序要求所有在此事务中被重复读取的数据的一致性,并且要求不允许进行其他修改——如果其他事务尝试更新读取器锁定的数据,这可能会影响多用户系统中的并发。当应用程序依赖于一致性数据,并且计划稍后在相同事务中修改数据时,这种级别是最合适的。

快照

应用程序要求长期运行多语句事务的绝对精确度,但不计划修改数据。应用程序要求所有在此事务中被重复读取的数据的一致性,但仅计划读取数据。不需要使用读取锁定来防止其他事务的修改,因为要等到数据修改事务提交或回滚,并且快照事务结束之后才可以看到更改。可以在此事务级别中修改数据,但是有可能与在快照事务启动后更新相同数据的事务产生冲突。这种冲突可以由每个更新事务来处理。具有多个读取器但只有一个编写器的系统(例如上述情境章节中的“复制的报告系统”)不会遇到冲突。

可序列化

应用程序要求长期运行多语句事务的绝对精确度,并且在事务完成之前必须保留来自其他修改的所有请求数据。此外,事务会请求一组数据而不仅仅是单独的几行数据。每组数据都必须在事务内的每个请求中产生相同的输出,并且对于预期的修改,不仅不能有任何用户可以修改已读的数据,而且还必须防止向组中输入新行。当应用程序依赖于一致性数据,计划稍后在相同事务中修改数据,并且即使在事务的最后都要求绝对的精确度和数据一致性时(在活动数据内),这种级别是最合适的。

 
我们假设有甲乙两条连接访问同一条纪录,甲将记录内容从 Marjorie 变换成 Hi,乙在事务过程中同时查询该条,搭配上表的不同事务级别,整体的示意图如图所示:
posted on 2010-05-04 16:32  小司  阅读(272)  评论(0编辑  收藏  举报