SQL Server-聚焦SNAPSHOT基于行版本隔离级别详解(三十)

前言

上一篇SQL Server详细讲解了隔离级别,但是对基于行版本中的SNAPSHOT隔离级别仍未完全理解,本节再详细讲解下,若有疑义或不同见解请在评论中提出,一起探讨。

SNAPSHOT行版本隔离级别

在SNAPSHOT隔离级别下,读取者在读取数据时, 它是确保获得事务启动时最近提交的可用行版本,这意味着,保证获得的是提交后的读取并且可重复读取,以及确保获得不是幻读,类似于SERIALIZABLE级别中一样,但是此隔离级别依赖于行版本,而不是使用共享锁,要想在企业部署的SQL Server实例中允许事务以SNAPSHOT隔离级别工作,首先需要在查询窗口执行以下代码打开快照隔离级别。如下:

ALTER DATABASE TSQL2012 SET ALLOW_SNAPSHOT_ISOLATION ON

下面我们再用一个简单的例子来详细讲解其过程。首先我们启用上述SNAPSHOT隔离级别,然后查询某个表的修改日期列,如下:

ALTER DATABASE AdventureWorks2012 SET ALLOW_SNAPSHOT_ISOLATION ON
GO

SELECT 
    ModifiedDate
FROM HumanResources.Shift

GO

如上是我们正常查询出的修改日期列(ModifiedDate)。接下来我们创建两个会话,一个是写入会话(会话一),另外一个是查询会话(会话二)来证明SNAPSHOT隔离级别的作用。

SET TRANSACTION ISOLATION LEVEL SNAPSHOT

BEGIN TRAN
UPDATE HumanResources.Shift
SET ModifiedDate = GETDATE()

GO

我们设置写入者的隔离级别为SNAPSHOT,然后更新其修改日期为当前日期,但是我们此时只是开启了事务并未提交该写入事务。与此同时我们再来创建一个查询会话(会话二)来查询修改日期列,如下查询会话也未提交事务。

SET TRANSACTION ISOLATION LEVEL SNAPSHOT

BEGIN TRAN
SELECT 
    ModifiedDate
FROM HumanResources.[Shift]

此时我们看到查询出的修改日期依然是原始值并未进行修改,此时我们再来提交写入者事务(会话一),在上述写入者事务后面添加如下一句。

COMMIT TRAN

此时再来在会话二中查询修改日期,结果依然是原始值,如下:

此时我们再来提交查询事务(会话二),再来查询,结果如下 

在上一篇仅仅只讲述了最后结果的变化,并未叙述其中过程到底是怎样的,请往下看。 

SNAPSHOT基于行版本隔离级别过程叙述

(1)会话一中开启事务并更新修改日期列,但是并未提交会话一中的事务,换句话说,原始值将依然有效,所以SNAPSHOT(快照隔离级别)导致仍然可以读取到原始值。

(2)会话二中开启事务并读取原始值,在这个阶段中,数据库引擎将创建一个读取的行副本到tempdb临时数据库中,所以在会话二中的所有读取事务都将从tempdb临时数据库中读取。

(3)会话一提交了事务并将其修改的值储存到了表中,注意,此时改变的值只是响应到了表中,而会话二中在tempdb临时数据库中副本依然保持不变。

(4)会话二再次读取行时,此时将从tempdb临时数据库中去读取且读取到的依然是原始值,因为在会话二中还并未提交事务。

(5)会话二提交了事务,此时将销毁在tempdb临时数据库中的副本,在此之后将无法再读取原始值。

(6)会话二再次读取行时,因为在提交事务之后在tempdb临时数据库中没有行,所以现在将去表中获取新行。

若我们在上述会话二中查询并未开启事务,这就意味着所有读取将直接从表中读取,同时将不会创建副本到tempdb临时数据库中,进一步讲,此时将导致查询阻塞,所以从这里我们知道开启基于行版本的SNAPSHOT隔离级别将有利于减少死锁情况的发生,提高并发性能。

总结 

本节我们再次很详细讲解了基于行版本的SNAPSHOT隔离级别的过程描述,总算是明白了基于行版本隔离级别的原理。

posted @ 2017-02-03 11:51  Jeffcky  阅读(2699)  评论(0编辑  收藏  举报