数据库原理.：第9章事务管理与控制.ppt

事务管理与控制 * 事务控制 * 第9章 事务管理与控制 解决问题： 多个用户同时操作数据库会不会相互干扰，从而导致数据的错误？ 系统在执行用户的请求过程中会不会出现故障，从而使数据库处于未知状态？ 并发控制问题 恢复问题 9.1 什么是事务 事务（Transaction）是并发控制和恢复的基本单位 完成用户一个特定工作的一组命令看作是事务，事务就是作业或任务 事务是构成单一逻辑工作单元的操作集合。 一个事务可以是一条SQL语句，也可以是多条SQL语句，但一定是一个完整的操作。例如银行转账业务 一个事务完成后应该告知系统，称为事务的提交（COMMIT），此时数据库处于操作后的正确状态；如果一个事务未完成，则必须清除该事务数据的影响，即事务的撤消（RollBack），从而使数据库处于操作前的正确状态。 9.1 什么是事务 事务（Transaction）是并发控制和恢复的基本单位，其是一个操作系列，这些操作具有以下四个属性（ACID）： 原子性（Atomicity） 事务中的操作要么执行，要么不执行，整个是一个不可分割的工作单位。 例如银行转账业务：从一个账号扣款和使另一个账号增加款额，这两个操作要么都执行，要么都不执行。所以应该把它们处理成一个事务。 9.1 什么是事务 一致性（Consistent） 必须保证多用户并发操作过程中数据的一致性 帐户甲 帐户乙 T1 T2 T3 X=400，X=X-40 数据的不一致性发生了 Return y 发生故障 Y=1000 银行转账业务 9.1 什么是事务 隔离性（Isolatable） 必须保证多用户并发操作过程中，相互不干扰。 帐户甲 帐户乙 帐户丙 T1 T2 X=400，X=X-40 甲和丙同时在T1时刻向帐户乙转帐，则对Y的值的修改是同时的，那么对于Y的值的修改都是错误的。 甲的操作：Y=Y+40=1040 丙的操作：Y=Y+100=1100 Y=1000 银行转账业务：甲向乙转去40元，丙向乙转去100元。 Z=200，Z=Z-100 2个不同的事务同时执行时交叉在一起，没有有效地进行隔离，从而使得他们之间产生了干扰。 9.1 什么是事务 持续性（Durative） 事务完成之后，它对于系统的影响是永久性的。即使出现了系统故障，那么系统在恢复之后已完成的事务对数据库的修改一直保持，未完成的事务将被回滚。 9.2 并发事务带来的问题 丢失更新问题 ——当多个事务同时选择一个元组，然后基于最初选定的值更新该元组时会发生丢失更新问题。 假设某产品库存量为50，现在购入该产品100个，执行入库操作，库存量加100；用掉40个，执行出库操作，库存量减40。分别用S1和S2表示入库和出库操作任务。同时发生入库（S1）和出库（S2）操作，这就形成并发操作。 丢失更新问题 表1　发生丢失更新的过程 用户A S1 时间 用户B S2 读库存量 T1 读库存量 库存量=50+100 T2 库存量=50-40 写库存量150 T3 写库存量10 例如，S1读取库存后，S2也读取了同一个库存；S1修改库存，回写更新后的值；S2修改库存，也回写更新后的值。此时库存为S2回写的值，S1对库存的更新丢失。如表1所示S1和S2的并发操作执行顺序，发生了“丢失更新”错误。 9.2 并发事务带来的问题 9.2 并发事务带来的问题 未提交依赖问题—称为读“脏数据”，查询一个已经被其他事务更新，但尚未提交的元组，会引起未提交依赖问题。 例：当S1和S2并发执行时，在S1对数据库更新的结果没有提交之前，S2使用了S1的结果，而在S2操作之后S1又回滚，这时引起的错误是S2读取了S1的“脏数据”。 用户A S1 时间 用户B S2 读库存量 T1 库存量=50+100 T2 T3 读库存量150 T4 库存量=150-40 撤消更新操作 T5 T6 写库存量110 表2 发生读“脏数据”的过程 9.2 并发事务带来的问题 不一致分析问题——不可重复读问题，很多应用可能需要校验功能，需要多次读数据，但由于其他事务的干扰，使得前后结果不一致，从而产生校验错误（不一致性的分析）问题。 用户A S1 时间 用户B S2 读库存量A=50，入库量B=100 T1 总库存量=50+100 T2 T3 读入库量B=100 T4 B=B/4 T5 回写B=25 读库存量A=50，入库量B=25 T6 校验总库存量=50+25，不一致 T7 当S1读取数据B后，T2执行了对B的更新，当T1 再次读取