【转修正】sql server行版本控制的隔离级别

摘要:
在SQLServer标准的已提交读隔离级别下,一个读操作会和一个写操作相互阻塞。为了满足这部分用户的需求,SQLServer2005也引入了这种机制,来实现类似的功能。所以选取行版本控制隔离级别也可以成为消除阻塞和死锁的一种手段。SQLServer有两种行版本控制,使用行版本控制的已提交读隔离和直接使用SNAPSHOT事务隔离级别。ALLOW_SNAPSHOT_ISOLATION数据库选项为ON时,SNAPSHOT事务通过使用行版本控制提供事务级读取一致性。在readcommitted隔离级别中,只在语句级别加锁,当语句执行完以后自动释放锁。

在SQL Server标准的已提交读(READ COMMITTED)隔离级别下,一个读操作会和一个写操作相互阻塞。未提交读(READ UNCOMMITTED)虽然不会有这种阻塞,但是读操作可能会读到脏数据,这是大部分用户不能接受的。有些关系型数据库(例如Oracle)使用的是另一种处理方式。在任何一个修改之前,先对修改前的版本做一个复制[WX1],后续的一切读操作都会去读这个复制的版本,修改将创建一个新的版本。在这种处理方式下,读、写操作不会相互阻塞。使用这种行版本控制机制的好处,是程序的并发性比较高,但是缺点是用户读到的虽然不是一个脏数据,但是可能是个正在被修改马上就要过期的数据值[WX2]。如果根据这个过期的值做数据修改,会产生逻辑错误。


[WX1]复制的内容保存在tempdb当中。

[WX2]假如读跟写同时进行,读到的不是现在正被修改的值,如果是读到正被修改的值那就是脏读了。读到的是修改前的值。但是这个值随时会过期。等到修改完就过期了。

有些用户可能为了更高的并发性而不在乎这种缺点,所以更喜欢Oracle的那种处理方法。为了满足这部分用户的需求,SQL Server 2005也引入了这种机制,来实现类似的功能。所以选取行版本控制隔离级别也可以成为消除阻塞和死锁的一种手段。

SQL Server有两种行版本控制,使用行版本控制的已提交读隔离(READ_COMMITTED_SNAPSHOT)和直接使用SNAPSHOT事务隔离级别。

  • READ_COMMITTED_SNAPSHOT数据库选项为ON时,READ_COMMITTED事务通过使用行版本控制提供语句级读取一致性。
  • ALLOW_SNAPSHOT_ISOLATION数据库选项为ON时,SNAPSHOT事务通过使用行版本控制提供事务级读取一致性。

下列示例可以说明使用普通已提交读事务,行版本控制的快照隔离事务和行版本控制的已提交读事务的行为差异。

数据库结构

手工创建数据库名称 HumanResources,执行以下脚本

CREATE TABLE [dbo].[Employee](
    [EmployeeID] [int] NULL,
    [VacationHours] [int] NULL,
    [SickLeaveHours] [int] NULL
) ON [PRIMARY]
GO
INSERT [dbo].[Employee] ([EmployeeID], [VacationHours], [SickLeaveHours]) VALUES (4, 48, 48)

实验1:Read Committed Isolation level

query1:事务1

--step1:开启第一个事务
BEGIN TRAN tran1
    --step2:执行select操作,查看VacationHours,对查找的记录加S锁
    SELECT EmployeeID, VacationHours
        FROM Employee 
        WHERE EmployeeID = 4;

    --step6: 在第一个事务中重新运行查询语句,发现查询被阻塞
    --这是因为在VacationHours上面有排他锁,现在要查询VacationHours字段又必须获得S锁,但是X锁与S锁冲突
    --所以不能执行查询,被阻塞.
    SELECT EmployeeID, VacationHours
        FROM Employee
        WHERE EmployeeID = 4;

    --step8:因为会话2已经提交了事务,不再阻塞当前查询,因此返回会话2修改好的新数据:40

--step9:回滚或者提交事务
ROLLBACK TRANSACTION;
commit tran tran1
GO

query2:事务2

--step3:开启第二个事务
BEGIN TRAN tran2;
    --step4:修改VacationHours,需要获得更新锁U,在VacationHours上有S锁,US不冲突,因此可以进行修改.
    --在修改VacationHours以后,更新锁U变成了排他锁X
    UPDATE Employee 
        SET VacationHours = VacationHours - 8WHERE EmployeeID = 4;

    --step5:在当前事务中查询VacationHours,发现只有40小时
    SELECT VacationHours
        FROM Employee
        WHERE EmployeeID = 4;

--step7:回滚事务
rollback tran tran2
--commit tran tran2

总结:

  1. 事务1中的读操作没有阻塞事务2中的写操作
  2. 事务2中的更新操作阻塞了事务1中后来的读操作,如下图所示:【转修正】sql server行版本控制的隔离级别第1张
  3. 事务1两次查询得到的数据分别是48跟40,两次获得的数据内容不一样。所以也成read committed为不可重复读。在read committed隔离级别中,只在语句级别加锁,当语句执行完以后自动释放锁。比如事务1中的第一次查询,虽然查询在事务中进行,并且事务没有提交,但是此时查询语句执行完以后在table上就找不到锁了。

实验2:SnapshotIsolation

此示例中,在快照隔离下运行的事务将读取数据,然后由另一事务修改此数据。快照事务不会被其他事务执行的更新操作所阻塞,它忽略数据的修改继续从版本化的行读取数据。也就是说,读取到的是数据修改前的版本。但是,当快照事务尝试修改已由其他事务修改的数据时,它将生成错误并终止。

query1:事务1,快照事务

--step1:启用快照隔离
ALTER DATABASE HumanResources
    SET ALLOW_SNAPSHOT_ISOLATION ON;
GO

--step2:设置使用快照隔离级别,前面没有设定是因为数据库默认的隔离界别就是Read Committed
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
GO

--step3:开启第一个事务
BEGIN TRAN tran1
    --step4:执行select操作,查看VacationHours,对查找的记录加S锁
    SELECT EmployeeID, VacationHours
        FROM Employee 
        WHERE EmployeeID = 4;

    --step8:在事务2中修改了数据以后,在事务1中再次运行查询语句
    --此时查询语句没有被阻塞,返回的值是48,也就是事务2修改之前的数据
    --这是因为事务1是从版本化的行读取数据 
    SELECT EmployeeID, VacationHours
        FROM Employee
        WHERE EmployeeID = 4;

    --step10:在事务2提交以后,事务1再次执行查询操作
    --发现查询结果还是48,这是因为事务依然从版本化的行中读取数据
    SELECT EmployeeID, VacationHours
        FROM Employee
        WHERE EmployeeID = 4;


    --step11:在事务2提交修改以后,事务1想再做任何修改时,这里我们修改SickLeaveHours字段的值
    --此时会遇到3960错误,事务1会自动回滚,事务2中的修改不会被回滚.
    UPDATE Employee
        SET SickLeaveHours = SickLeaveHours - 8WHERE EmployeeID = 4;

    --附:假如事务2中执行了修改操作,但是没有提交,此时在事务1中执行修改操作会被阻塞
    --此时如果提交事务2中的修改操纵,事务1会遇到3960错误,跟上面一样.
    UPDATE Employee
        SET SickLeaveHours = SickLeaveHours - 8WHERE EmployeeID = 4;

rollback tran tran1
commit tran tran1
/*Msg 3960, Level 16, State 2, Line 1
Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to
 access table 'Employee' directly or indirectly in database 'AdventureWorks' to update,
  delete, or insert the row that has been modified or deleted by another transaction. Retry the 
  transaction or change the isolation level for the update/delete statement.
*/
--实验2结束------------------------------------

query2:事务2

--step5:开启第二个事务
BEGIN TRAN tran2;
    --step6:修改VacationHours,需要获得更新锁U,在VacationHours上有S锁,US不冲突,因此可以进行修改.
    --在修改VacationHours以后,更新锁U变成了排他锁X
    UPDATE Employee 
        SET VacationHours = VacationHours - 8WHERE EmployeeID = 4;

    --step7:在当前事务中查询VacationHours,发现只有40小时
    SELECT VacationHours
        FROM Employee
        WHERE EmployeeID = 4;

--step9:提交事务2
commit tran tran2
--实验2结束------------------------------------

总结:

  1. 快照事务1的读操作没有阻塞普通事务2的读操作,但是阻塞了事务2的删除操作,如果在事务2中执行delete操作的话会报错:Employees cannot be deleted. They can only be marked as not current.Msg 3609, Level 16, State 1, Line 1The transaction ended in the trigger. The batch has been aborted.
  2. 普通事务2的更新操作,没有阻塞事务1的读操作,但是我们发现事务1中读到数据是事务2更新之前的内容。因为读取的是版本化中的行数据。

在上述实验中,我们发现下面两条语句使一起使用的,也就是首先允许数据库开启snapshot isolation,然后再将isolation level设定为snapshot。

复制代码
--step1:启用快照隔离
ALTER DATABASE AdventureWorks
    SET ALLOW_SNAPSHOT_ISOLATION ON;
GO

--step2:设置使用快照隔离级别,前面没有设定是因为数据库默认的隔离界别就是Read Committed
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
GO
复制代码

在执行完step1以前,我们可以在sys.databases中查看AdvantureWorks的snapshot_isolation_state和is_read_committed_snapshot_on这两个属性:

SELECT name,snapshot_isolation_state, snapshot_isolation_state_desc, is_read_committed_snapshot_on 
FROM sys.databases where name='AdventureWorks';

查询结果如下图所示:

【转修正】sql server行版本控制的隔离级别第4张

假如我们不执行step1,只执行step2,然后开启事务进行查询,会报如下错误:

Msg 3952, Level 16, State 1, Line 3
Snapshot isolation transaction failed accessing database 'AdventureWorks' becausesnapshot isolation is not allowedin this database. Use ALTER DATABASE to allow snapshot isolation.

执行完step1以后,我们再次查看sys.databases中的内容,发现snapshot_isolation_state由0变为1,如下图所示:

【转修正】sql server行版本控制的隔离级别第5张

实验3:使用行版本控制的已提交读隔离(READ_COMMITTED_SNAPSHOT)

在此示例中,使用行版本控制的已提交读事务与其他事务并发运行。已提交读事务的行为与快照事务的行为有所不同。与快照事务相同的是,即使其他事务修改了数据,已提交读事务也将读取版本化的行。与快照事务不同的是,已提交读将执行下列操作:

  • 在其他事务提交数据更改后,读取修改的数据。
  • 能够更新由其他事务修改的数据,而快照事务不能。

query1:事务1

--实验3:READ_COMMITTED_SNAPSHOT -------------------

--stpe1:启用行版本控制的已提交读
--注意运行这句话的时候,不可以有其他连接同时使用AdventureWorks
use master
ALTER DATABASE HumanResources
    SET READ_COMMITTED_SNAPSHOT ON
    WITH ROLLBACK IMMEDIATE
GO

--step2:设置使用已提交读隔离级别
USE HumanResources;
GO
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
GO

--step3:开启第一个事务
BEGIN TRAN tran1
    --step4:执行select操作,查看VacationHours,对查找的记录加S锁
    SELECT EmployeeID, VacationHours
        FROM Employee 
        WHERE EmployeeID = 4;

    --step8:在事务2中修改了数据以后,在事务1中再次运行查询语句
    --此时查询语句没有被阻塞,返回的值是48,也就是事务2修改之前的数据
    --这是因为事务1是从版本化的行读取数据 
    SELECT EmployeeID, VacationHours
        FROM Employee
        WHERE EmployeeID = 4;

    --step10:在事务2提交以后,事务1再次执行查询操作
    --这里和实验2不同,事务1始终返回已提交的值,所以这里返回40,因为会话2已经提交了事务
    SELECT EmployeeID, VacationHours
        FROM Employee
        WHERE EmployeeID = 4;

    --step11:这里修改会成功,不会报错.
    UPDATE Employee
        SET SickLeaveHours = SickLeaveHours - 8WHERE EmployeeID = 4;

rollback tran tran1
--实验3结束------------------------------------

query2:事务2

--step5:开启第二个事务
BEGIN TRAN tran2;
    --step6:修改VacationHours,需要获得更新锁U,在VacationHours上有S锁,US不冲突,因此可以进行修改.
    --在修改VacationHours以后,更新锁U变成了排他锁X
    UPDATE Employee 
        SET VacationHours = VacationHours - 8WHERE EmployeeID = 4;

    --step7:在当前事务中查询VacationHours,发现只有40小时
    SELECT VacationHours
        FROM Employee
        WHERE EmployeeID = 4;

--step9:提交事务2
commit tran tran2
--实验3结束------------------------------------

总结:

  1. 在事务2修改数据之后,提交之前,事务1中读到的是快照数据,也就是事务2没有修改之前的值。
  2. 在事务2提交修改之后,事务1读到了修改之后的数据。并且事务1可以修改由其他数据修改了的数据。

结论

  1. 使用 sys.databases 目录视图可以确定两个行版本控制数据库选项的状态。
  2. 对用户表和存储在 master 和 msdb 中的某些系统表的任何更新都会生成行版本。
  3. 在 master 和 msdb 数据库中,ALLOW_SNAPSHOT_ISOLATION 选项自动设置为 ON,并且不能禁用。
  4. 在 master 数据库、tempdb 数据库或 msdb 数据库中,用户不能将 READ_COMMITTED_SNAPSHOT 选项设置为 ON。
  5. 从上面的测试可以看到,原先会发生阻塞的两个会话在使用行版本控制的隔离级别后,都不会遇到阻塞了。但是两种行版本控制的结果又有不同。可以用表1来总结。

表1 使用行版本控制隔离级别后的不同

会话1

会话2

结果

A. 普通已提交事务

B. 使用快照隔离

C. 使用行版本控制的已提交读

BEGIN TRAN

查询1

48

BEGIN TRAN

修改1

成功

查询1

40

查询2

被阻塞

48

COMMIT TRAN

查询2返回40

查询3

40

48

40

修改2

ROLLBACK TRAN

成功

失败

成功

免责声明:文章转载自《【转修正】sql server行版本控制的隔离级别》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇项目部署到Tomcat服务器上面,jS文件乱码问题u-boot start.S启动文件分析下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

全库修改SQL Server现有排序规则

SQL Server备份还原后可能遇到排序规则不一致的问题,此时通过统一排序规则可以解决。详细操作如下: 数据库报错信息: 无法解决 equal to 运算中 "SQL_Latin1_General_CP1_CI_AS" 和 "Chinese_PRC_CI_AS" 之间的排序规则冲突。 为解决排序规则冲突,可直接修改对应字段的排序规则,使其一致则可避...

Oracle向MySQL迁移的注意点整理

1. 表结构 * 数据库设计工具: 连接Oracle拉取表字段信息, 调整数据库类型后, CM创建MySQL版本的创建表语句 * https://github.com/hepengju/ExcelVBAUtils 2. 表数据 * 数据迁移工具: 配置好数据库的来源和目标, 配置好需要同步的表, 直接JDBC查出来set进入, 1...

分布式事务 XA 两段式事务 X/open CAP BASE 一次分清

分布式事务:   分布式事务是处理多节点上 的数据保持 类似传统 ACID 事物特性的 一种事物。 XA:是一种协议,一种分布式事务的协议,核心思想是2段式提交。 1 准备阶段  2 提交阶段。XA协议是 Tuxedo 首先提出的      XA 的 原理 ,XA分了 几个角色,RM ,TM ,AP 等   RM:资源管理器。他记录着XA的 事物的全部 状...

SQL跨数据库复制表数据

不同服务器数据库之间的数据操作 不同数据库之间复制表的数据的方法: 当表目标表存在时: insert into 目的数据库..表 select * from 源数据库..表 当目标表不存在时: select * into 目的数据库..表 from 源数据库..表 --如果在不同的SQL之间: insert into openrows...

SAP MM 事务代码MI31之思考

SAP MM 事务代码MI31之思考 1 - MI01之痛 多年SAP项目实施实践中,笔者之前对于SAP系统里盘点凭证创建(MI01)事务代码里的输入界面很是不爽: 第一,MI01输入了一行数据以后,回车,系统就隐藏了之前输入的数据,需要点击其它按钮或者菜单才能看到。这个很不方便啊,不管别人使用体验如何,反正笔者是很不爽! 第二,MI01 界面里对于数据批...

Spring嵌套事务

Spring 事务传播属性如下     PROPAGATION_REQUIRED--支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择。   PROPAGATION_SUPPORTS--支持当前事务,如果当前没有事务,就以非事务方式执行。   PROPAGATION_MANDATORY--支持当前事务,如果当前没有事务,就抛出异常。   P...