事务(transaction).ppt

1、7.3.1 事务,事务（transaction） 事务是数据库的逻辑工作单位，由用户定义的一个组数据库操作序列组成，序列中的操作要么全做要么全不做。 该操作命令序列是一个不可分割的工作单位。一个事务可以是一条SQL语句、一组SQL语句或为此编写的整个程序。 事务的例子 银行转帐：A帐户转帐到B帐户100元。该处理包括了两个更新步骤： A=A-100 B=B+100 这两个操作是不可分的：要么都做，要么都不作。 在DBMS中提供事务管理的部件称为事务管理器（transaction manager）。事务管理器保证每个事务执行前后的数据库状态都是一致的。,7.3.1.1 事务的基本控制操作,事务开

2、始：BEGIN TRANSACTION 事务提交：COMMIT TRANSACTION 告诉事务管理器事务中的所有操作都已完成，将所有对数据库的更新写回到物理数据库中，事物正常结束，数据库又处于一个新的一致状态； COMMIT操作为事务建立了一个提交点（COMMIT POINT）。 事务回退：ROLLBACK TRANSACTION 告诉事务管理器事务执行时发生故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤消，回滚到事务开始的壮态。,Begin Transaction A=A-100 If B不存在 Then Rollback Transaction Else B=B+1

3、00 Commit Transaction End If,7.3.1.2 事务的特征ACID,原子性（Atomicity） 事务是不可分的原子，其中的操作要么都做，要么都不做。 一致性（Consistency） 事务的执行保证数据库从一个一致状态转到另一个一致状态，即数据不会应事务的执行而导致不一致，但一个事务的内部无须一致。 隔离性（Isolation） 多个事务一起执行时相互独立，任一事务的执行结果直到其成功提交后才对其它事务可见。多个事务并发执行与这些事务单独顺序执行的结果相同。 持续性（Durability） 事务一旦成功提交，就在数据库永久保存，关机后依然存在。 事务的4个特征一般统

4、称为事务的ACID性质。DBMS中的任一事务都由事务管理器保证了ACID。 事务在ACID特性可能遭到破坏的因素： 多个事务并行运行时，不同事务的操作交差执行； 事务在运行过程中备强行停止。,7.3.1.3 事务的ACID性质举例,T1事务： 从A帐户中转帐100元到B帐户中 T2事务：从A帐户中取100元,T1 Read(A) A=A-100 Write(A) Read(B) B=B+100 Write(B),T2 Read(A) A=A-100 Write(A),一致性 T1单独执行时A+B应不变，如果只Write(A)没有Write(B)，就不一致。T1、T2并发执行时，A应去掉200元

5、，否则不一致。 原子性 T1 必须全部执行6个操作，否则违反原子性。 独立性 T1、T2相互应不影响，不产生数据错误。 持久性 T1执行后，对数据库的修改持久存在。,7.3.2 数据库并发控制,并发控制就是要求DBMS提供并发控制功能来合理调度并发事务，避免并发事务之间的互相干扰造成数据的不一致性。,7.3.2.1 数据库并发控制概述,数据库系统允许多个用户同时存取数据库。 并发操作 在多用户DBS中，如果多个用户同时对同一数据进行操作称为并发操作。 并发操作使多个事务之间可能产生相互干扰，破坏事务的隔离性（Isolation）。并发操作通常会引起三类问题： 丢失更新 脏读 不一致分析 DBM

6、S的并发控制子系统负责协调并发事务的执行，保证数据库的一致性，避免产生不正确的数据,数据库并发操作实例丢失修改,丢失修改 甲、乙两个事务读同一数据并进行更新，乙事务的修改结果破坏了甲的更新结果。 例如: 并发取存款操作。假设存款余额X1000元，甲事务取走存款300元，乙事务取走存款200元，存款余额更新后应是X500元。倘若甲事务执行完毕之后再执行乙事务则可队得到正确的结果。倘若甲、乙事务并行，按如图3所示的序列交叉执行，将会出现错误结果。 事务甲 读x 更新x:=x-300 时间T t1 t2 t3 t4 t5 事务乙 读x 更新x:=x-200,数据库并发操作实例读“脏”数据,读“脏”数

7、据 事务甲更新了数据x，事务乙读了甲更新后的数据x，事务甲由于某种原因被撤消，修改无效，数据x恢复原值。事务乙得到的数据与数据库内容不一致。,时间t,事务T1,事务T2,t1,t2,t3,t4,T1更新 读 X =100 X = X*2 写 X = 200,T2检索 读 X = 200,T1回滚 ROLLBACK X 恢复为100,原因:并发操作破坏事务的隔离性,数据库并发操作实例读过时数据,读过时数据 事务甲读取数据x，事务乙读取并更新了数据x，事务甲再次读取x以进行校核，得到的两次读取值不一致。,时间t,事务T1,事务T2,t1,t2,t3,t4,T1检索 读 X = 100 X = X*

8、2 写 X = 200,T2更新 读 X = 200 X = X+50 写 X = 150,T1检索(验算) 读 X1 = 100 X1 = X1*2 X1与X不一致 = 200,原因:并发操作破坏事务的隔离性,并发操作的调度,并行事务正确性的唯一准则是可串行性。 可串行性 几个事务的并行执行时的结果与串行地执行它们时的结果相同。则表示该并发事务是可串行性。 不可串行性,时间t,事务T1,事务T2,t1,t2,t3,t4,T1 读 X1 =100,T2 读 X2 = 200,T1 X2 = X1+5 写 X2,T2 X1 = X2+10 写 X1,问题如何解决,一种方法：让所有事务一个一个地串

9、行执行 一个事务在执行时其它事务只能等待 不能充分利用系统资源，效率低下 另一种方法：采用封锁技术，允许事务并发执行。 但必须保证事务并发执行的正确性 必须用正确的方法调度执行事务的并发操作,7.3.3 封锁,1. 封锁 所谓封锁就是事务T在对某个数据对象(例如表、记录等)操作之前，先向系统发出请求，对其加锁。加锁后事务T对该数据对象就有了一定的控制，在事务T释放它的锁之前，其他事务不能更新该数据。 2.封锁类型 排它锁（X锁） 共享锁（S锁） 3. 封锁协议 对数据对象加锁时须遵循的规则 4. 封锁的粒度 封锁对象的大小。对象可以时表、关系、记录和字段。,7.3.3.1 封锁类型,排它锁（X

10、锁或写锁） 若事务T对数据对象A 加上X锁，则只允许事务T读取和修改A，其他任何事务都不能再对A 加任何类型的锁，直到T释放A上的锁。 共享锁（S锁或读锁） 若事务T对数据对象A 加上S锁，则只事务T读取A 但不能修改A，其他事务只能再对A 加S锁，而不能加X锁，直到T释放A上的S锁。,7.3.3.2 封锁协议,保证并行调度可串行性的封锁协议 二级锁协议 事务对任何数据进行读写操作之前，必须先对其进行封锁；在释放一个封锁之后，事务不再申请和获得任何其它封锁。该封锁将解决丢失更新和防止读“脏”数据。 保证数据一致性的封锁协议：三级封锁协议 一级封锁协议 事务T在修改数据R之前必须先对其加X锁，直

11、到事务结束才释放。该封锁将解决丢失更新。 二级封锁协议 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。解决丢失更新和防止读“脏”数据。 三级封锁协议 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放S锁。解决保证数据一致性问题。,7.3.3.3 封锁带来的问题,锁机制可能引起死锁与活锁 死锁（Dead Lock）：两个或更多的事务同时处于等待状态，每个事务都在等待其中另一个事务解除封锁，它才能继续执行下去，结果造成任何一个事务都无法继续执行。 活锁（Live Lock）：系统可能使某个事务永远处于等待状态，得不到封锁得机会。,活锁,事务1

12、,事务2,XLock ,XLock,Wait ,Unlock,Wait ,事务3,XLock,Wait ,XLock ,UnLock,事务4,XLock,Wait ,XLock ,Wait ,Wait ,死锁,事务1,事务2,A,B,X,X,7.3.3.4 封锁的解决方法,死锁解决方法： 一次加锁法 顺序加锁法 死锁的诊断 超时法 等待图法 活锁解决方法 采用“先来先服务”得策略,SQL Server中的封锁,封锁的粒度 行、页、页组、表、数据库 封锁的类型 共享封锁 独占封锁 SQL Server对更新语句使用独占锁 意图封锁 建立一个锁定层，其它事务不能获得更高层次的锁 更新封锁 模式锁

13、保证表或索引被另一个用户使用时不会被删除或被修改结构,SQL Server中的封锁命令,在查询和更新语句中使用“WITH()”指定表级封锁的方式和范围。封锁类型： ROWLOCK 对记录实施共享式封锁 PAGLOCK 对页实施共享式封锁 TABLOCK 对表实施共享式封锁 TABLOCKX 对表进行独占式封锁 HOLDLOCK：与TABLOCK一起使用，可将共享锁保留到事务完成，可保证数据的重复读特性 NOLOCK 对表不进行封锁，仅用于SELECT语句 UODLOCK 对表中指定的记录实施更新封锁，这时其它用户不允许对表实施共享锁和独占式封锁 注意：SQL Server 查询优化器自动作出正

14、确的决定。建议仅在必要时才使用表级锁定提示更改默认的锁定行为。,7.4 数据库的恢复,当数据库系统发生故障，造成数据库中全部或部分数据丢失时，DBMS必须具有检测故障并把数据库恢复到故障发生前的某一已知的正确状态功能。,7.4.1 数据库恢复的基本原理和方法,基本原理 冗余（Redundancy） 数据库在逻辑设计时一般无冗余，但为了可恢复，要保证物理存储上的冗余。 实现方法 定期备份（转储）整个数据库，建立副本。 建立事务日志 通过备份和日志进行恢复,7.4.1.1 数据备份,恢复机制的关键技术： 如何建立冗余数据？ 如何利用这些冗余数据？ 数据备份（转储） 静态备份：备份期间不允许对DB操

15、作 动态备份：备份期间允许操作DB 海量备份：备份全部数据 增量备份：每次只备份自上一次海量备份后更新的数据 实际中一般是结合各种方法实施备份,7.4.1.2 事务日志,日志文件 记录用户对数据库的每一次更新操作具体细节的文件。 日志记录了所有更新操作的具体细节 操作类型 (插入、删除、修改) 执行操作的事务标识 操作对象 更新前值（插入为空） 更新后值（删除为空） 更新时间 DBMS可利用日志来恢复被更新对象的旧值,先写日志原则,把对数据的修改写到数据库中和把表示该修改的日志记录写道日志文件中是两个不同的操作。有可能在这两个操作之间发生故障，即两个写操作只完成了一个，为了保证数据库的可恢复，

16、必须先把更新记录写到日志文件中，然后再写数据库修改。,先写日志 ,设T1将A修改为900时发生故障。设此时900已写到数据库，但还未来得及写到日志中。 根据恢复策略，T1在恢复应UNDO，但此时由于后写日志，A的更新操作在日志中没有记录，因此无法将A恢复到1000 如果先写日志，则即使没有写到数据库中，也只不过多执行一次UNDO操作，不会影响数据库的正确性。,后写日志 ,利用备份副本和日志进行恢复策略,t0,t1,t2,备份,运行事务,故障发生点,登记日志文件,重装副本,利用日志文件进行恢复,继续运行事务,登记日志文件,介质故障恢复,系统故障和事务故障恢复,当发生故障时： （1）若是介质故障，

17、则首先重装副本。 （2）利用日志文件进行事务故障恢复和系统故障恢复，一直恢复到故障发生点。,时间,7.4.2 数据库系统故障种类,故障种类 事务故障、介质故障、系统故障、计算机病毒、人为故障。 事务故障：发生在单个事务内部的故障 可预期的事务故障：即应用程序可以发现的故障，如转帐时余额不足。由应用程序处理； 非预期的事务故障：如运算溢出、死锁等，导致事务被异常中止。应用程序无法处理此类故障，由系统进行处理。 介质故障：一般指磁盘损坏 介质故障是对系统影响最为严重的一种故障。导致磁盘数据丢失，破坏整个数据库。 系统故障： 软故障（Soft Crash），由于OS、DBMS软件问题或断电等问题导致

18、内存数据丢失，但磁盘数据仍在。 影响所有正在运行的事务，但不破坏整个数据库。 计算机病毒 人为故障,7.4.3 检查点,当系统故障发生时，需要搜索整个日志来确定UNDO列表和REDO列表 搜索过程太耗时，因为日志文件增长很快 会导致最后产生的UNDO和REDO列表很大，使恢复过程变得很长。 解决方法：建立检查点（Checkpoint） 在当前已经开始的所有事务都结束之前不启动任何事务 将当前内存中的所有日志记录输出到稳定存储器上 将缓冲区的内容写入物理数据库 将检查点记录写入日志,可预期的事务故障恢复,恢复方法 由应用程序（事务发起者）显式地调用Rollback取消事务执行。,例如， 从A帐户

19、转100元到B帐户 Declare a Number:=0; Begin Update account Set balance=balance-100 Where ID=A; Select count(*) Into a From account where ID=B; If a=0 then Rollback; Else Update account Set balance=balance+100 where ID=B; End If Commit; End;,不可预期事务故障恢复,不可预期的事务故障 当一个事务未到达终点时被异常中止，未完成事务的更新操作有可能已写入数据库（立即更新）。 根据日志文件执行UNDO恢复，方法是： 反向扫描日志文件（从最后向前扫描） 对每个更新操作执行逆操作（插入删除，删除插入，修改改为旧值） 直到到达事务的开始标记,T1 Read(A) A=A-100 Write(A) Read(B) B=B+100 Write(B),发生故障时的日志 ,恢复： Let B1000 Let A1000,由系统自动完成恢复,介质故障恢复,操作系统避免介质故障的技术 双机热备份；磁盘镜像；冗余磁盘阵列等 数据库管理系统避免介质故障的技术 数据库备份，即建立副本 数据库管理系统介质故障的恢复方法 重装最近的副