第五次作业—的事务隔离等级.docVIP

事务隔离级别 一、事务的概念 事务(transaction)是用户定义的一个数据库操作序列，这些操作要么全运行，要么不执行其中任何一个操作，它是一个不可分割的工作单元。为了保证数据库的完整性，我们要求数据库管理系统维护事务的几个性质：原子性(Atomicity)、一致性(Constancy)、隔离性(Isolation)、持久性(Durability)，简称为特性ACID。 二、事务的隔离性 即使每个事务都能确保一致性和原子性，但当几个事务并发执行时，它们的操作指令会以某种人们所不希望的方式交叉执行，这也可能导致不一致性的状态。隔离性要求系统必须保证事务不受其他并发执行事务的影响，也即要达到一种效果：对于任何一对事务T1和T2，在T1看来，T2要么在T1开始之前已经结束，要么在T1完成之后再开始执行。这样，每个事务都感觉不到系统有其他事务在并发地执行。 三、并发操作带来的问题 (1)丢失修改(Lost Update)。 两个事务和读入同一数据并修改，提交的结果破坏了提交的结果，导致的修改被丢失。丢失修改又称为写-写错误如图。 例如，假定有两个顾客甲和乙，甲往帐户里存入500元，乙从帐户A里取出200元，帐户A初始余额为2000元。考虑这样一个活动序列：甲和乙一次读取帐户A的余额A，甲先存款修改余额A=A+500，所以，A为2500元，把写回数据库，乙再取款修改余额A=A-500，所以A为1800元，把A写回数据库，最终余额为1800元。或者在依次读取账户A的余额后，乙先取款完成后，甲再存款，最终余额为2500元。这会导致甲往账户A的存款500元或乙从账户A的取款2000元不知所踪。原因就在于最终数据库里只反映出了乙取款的修改结果，甲存款的修改结果丢失了或反之。 图1 丢失修改 之所以发生这种不一致现象，是由于两个事务同时修改一个数据项而导致的。正如前面所提到的，一般DBMS在事务修改数据之前，都要求先获得数据上的排他锁，所以实际中不会出现两个事务同时修改同一数据的情况。 （2）脏读（Dirty Read）。 事务T1修改某一数据，并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤销，这时T1已修改过的数据恢复原值，T2读到的数据就与数据库中的数据不一致，则T2读到的数据就为“脏”数据，即不正确的数据。脏读又称做写-读错误，如图2所示。 图2 读脏数据 提交意味这在确认，确认事务的修改结果真正反映到数据库中了。而在事务提交之前，事务的所有活动都处于一致不确定状态，各种各样的故障都可能导致它的中止，既不能保证它的后动最终能反映到数据库中。如果恰事务基于未提交事务的中间状态来做进一步的处理，那么它的结果很可能是可靠的，正如我们不能依靠草稿上的蓝图来盖楼一样。如果一个事务是对一张大表进行统计分析，那么它读取了部分脏数据对其结果来说是无甚妨碍的。但如果一个存款事务正在向某帐户上存入500元，那么取款事务这时就不能对该帐户执行取款，否则很可能会出现下情况，既存款事务失败了，它所存入帐户的资金被撤销掉，但这笔资金却可能被取走。 (3)不可重读(Non-Repeatable Read) 事务T1读取某一数据后，事务T2对其做了修改，当T1再次读取该数据时，得到与前次不通的。不可重复读又称做读-写错误，如图3所示 图3不可重复读 (4)幻象读(Phantom Read) 事务T2按一定条件读取了某些数据后，事务T1插入(删除)了一些满足这些条件的数据，当T2再次按相同条件读取数据时，发现多(少)了一些记录。对于幻象这种情况，即使事务可以保证它所访问到的数据不被其他事务修改也还是不够的，业务如果只是控制现有的数据的话，并不能组织其他事务插入新的满足条件的元组。 四、事务隔离的级别 SQL92标准中定义了4级事务隔离级别(isolation level)。这个隔离标准阐明了在并发控制问题中允许的操作，以便使应用程序编程人员能够声明将使用的事务隔离级别，并且由DBMS通过管理封锁来实现相应的事务级别。表1给出了每一隔离级别及在此隔离级别下可能产生的不一致现象。 (1)未提交读(Read Uncommitted) 未提交读又称脏读，允许运行在该隔离级别上的事务读取当前数据页上的任何数据，而不管该数据是否已经提交。设置隔离级别为未提交读，解决了丢失修改问题。 使用未提交读会牺牲数据的一致性，当然带来的好处就是高并发性，因此不能将财务事务的隔离级别设置成未提交读。但在注入预测销售趋势的决策支持分析中，完全精确的结果是不必要的，这时用未提交读是合适的。 (2)提交读(Read Committed) 提交读是保证允许在该隔离级别上的事务不会读取其他未提交事务所修改的数据，解决了丢失修改和脏读问题。 (3)可重