您的位置:首页 > 数据库

八张图教你彻底理解数据库并发控制之隔离级别(中)

2012-05-02 12:52 381 查看

八张图教你彻底理解数据库并发控制之隔离级别(中)

一、更新丢失

第一个问题来源于两个事务对同一个数据进行修改,引起数据修改最终结果的不确定性。更形象一点,甲乙两童鞋同时在网上订飞机票,甲童鞋瞄中了一张机票,这时乙童鞋也开始找机票,正好找到甲童鞋的那张。这样看来,由于乙童鞋的这个中间冒出个程咬金的行为,甲童鞋订机票这个事务的原子性就被打断,从此一分为二不再不构成原子性,问题即将出现。甲童鞋提交了订单,机票上有了甲童鞋的名字,这时候乙童鞋也提交了订单,然后机票上便有了乙童鞋的名字,由于乙童鞋是后提交,所以覆盖了甲童鞋提交的定单。可怜的甲童鞋,并不知道自己并木有订到机票。然后,就木有然后了……

我们首先来看看数据库系统在这个过程中,到底做了神马事情。首先甲童鞋将机票信息从硬盘提取到内存(此时并未加任何锁,当然在现代数据库系统中,不加锁而读取数据的行为是不可能出现的),准备修改。然而就在这准备修改的一瞬间,乙童鞋也正好在内存中找到了此条记录,这是看到的还是甲童鞋修改之前的值。接下来,甲童鞋也对内存中的该机票信息进行修改,同时提交,数据由内存写回硬盘,乙童鞋依然对甲童鞋修改之前的数据进行修改并提交,数据再次写回硬盘,因为先前甲童鞋提交的记录与乙童鞋提交的记录在数据库中是同一条记录,所以一来二往的,乙童鞋的记录就把甲童鞋的记录覆盖了。这个过程,相关数据库理论的书中的叫法为——“更新丢失”,深刻且形象的论证了甲童鞋更新数据然后丢失更新这个过程。

当然,更新丢失这个问题在现代的数据库系统中根本不会存在,目前现代数据库操作系统中的四个隔离级别UR,CS,RS,RR中的最低隔离级别的UR已经充分的解决了这个问题。下面将用实验说明隔离级别UR是如何防止此类事件发生的。

实验环境为AIX中的DB2数据库9.5版本,如果各位要问为什么要用这个环境。我的回答是:第一,一般的工业生产环境用的都是这个配置,更具有代表性;第二,除了这个环境,我还真找不到其他环境来进行这个实验。

我们使用的表结构和原始数据如下图所示:



然后打开两个连接,其作用相当于模拟两个会话。通过set current isolation UR 命令将各自会话的隔离级别设置为UR,同时关闭自动提交,至于如何关闭自动提交,方法有很多,网上到处都是,这里就不介绍了。步骤如下:

步骤一:会话一修改ID为1的记录,但不提交该操作。

步骤二:会话二修改同一条记录,结果会话二被卡住了,除非会话一进行提交或者回滚,会话二才能继续进行。



我们对此过程进行仔细思考,不难找出其实质。首先会话一在将数据读取到内存之后,对该数据加上X锁,同时对数据进行修改。当会话二想读取该数据时,首先在内存中查找,这时发现该数据已经被会话一加锁,所以会话二只能等待该数据的X锁被撤销。而除非会话一进行提交或者回滚,才能撤销该数据的X锁。

二、未提交的读

更新丢失是对单行记录进行操作时可能会出现的第一个状况,接下来我们看看对单行记录进行修改中可能会出现的第二种状况——未提交的读。我们仍以甲乙两童鞋购买机票为例子,要深刻形象的描述这一现象。乙童鞋在网站上找到了最后一张从26日北京飞往昆明的机票,然后修改该机票信息,但并未提交,乙童鞋正好也想要这张机票,但是查找时发现机这张票信息已经被卖出,这时候不得已只好定另外的机票,然后甲童鞋忽然一个大脑短路,不再想要这张机票,回滚事务,那么这张机票又空了出来。那之前乙童鞋看到的便是尚未提交的机票信息,从而导致乙童鞋木有买到自己想要的机票。

我们从实例图再来看看这个状况,

步骤1:在会话一中修改id为1的记录,将其name属性修改为“修改”。

步骤2:在会话二中查看id为1的记录,发现其name属性已经被修改为“修改”。

步骤3:在会话一中回滚刚才的操作。

步骤4:在会话二中查看id为1的记录,发现其name属性仍为“test1”。



从图中我们看到,步骤二是个神奇的步骤,它读到了一个尚未提交的神奇的数据,然后导致出一个神奇的结果!当然,这种情况者目前的数据库产品中也不大可能出现。对于大多数数据库产品而言,默认的隔离级别为CS,而这个级别便杜绝了此类情况的出现。下面我们仍以DB2为例,说明这个问题。首先通过set current isolation CS将两个会话的隔离级别修改为CS,然后按以下步骤进行操作:

步骤一:在会话一中进行修改id为1的数据的操作,但不进行提交。

步骤二:在会话二中查看在会话一中被修改了的id为1的数据,发现操作被卡住,除非会话一进行提交或者回滚,操作才能继续下去。



首先在CS的隔离级别下,会话一将id为1的记录读取至内存,同时加X锁并修改,由于并未提交,所以修改过的记录保存在内存中。当会话二欲对id 为1的数据进行修改时,他需要对该记录加S锁,但当它发现该记录在会话一的内存空间中且被加上X锁时,它只有等待X锁的解除。如此一来,在CS级别下便不会出现未提交读的问题。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: