chap5-事务处理、并发控制与恢复技术.ppt

第5章 事务处理、并发控制 与恢复技术 本章目标 本章结束时，学员能够： n了解事务的概念和ACID特性 n掌握并发控制和封锁技术的概念 n理解并发调度的可串行性及两段锁协议 n了解封锁粒度 n了解数据库系统的故障种类 n理解数据库恢复的实现技术和常见故障的恢 复策略 n了解数据库镜像技术 5.1事务的基本概念 n事务的概念： 所谓事务是用户定义的一个数据库操作序 列，这些操作要么全做要么全不做，是一个 不可分割的工作单位。 例如，在关系数据库中，一个事务可以是 一条SQL语句、一组SQL语句或整个程序。 事务是一个逻辑工作单元，同时又是一个 恢复单元 一个事务提交之后，数据库又处于或应该 处于一个一致性状态 5.1事务的基本概念 n“一荣俱荣，一损俱损”这句话很能体现事务的思想 ，很多复杂的事物要分步进行，但它们组成一个整 体，要么整体生效，要么整体失效。这种思想反映 到数据库上，就是多个SQL语句，要么所有执行成 功，要么所有执行失败。 5.1.1 事务 (续) n定义事务的三条语句： BEGIN TRANSACTION COMMIT ROLLBACK SQL中事务以Begin transaction开始，以Commit 或 Rollback 结束 Commit 表示提交，即提交事务的所有操作，事 务正常结束。 Rollback 表示事务非正常结束，撤消事务已做的 操作，回滚到事务开始时状态 SQL Server 的事务模式： n自动提交事务 每条单独的语句都是一个事务。每条语句后都隐含一个 COMMIT n显式事务 每个事务均以 BEGIN TRANSACTION 语句显式开始，以 COMMIT 或 ROLLBACK 语句显式结束。 n隐性事务 在前一个事务完成时新事务隐式启动，但每个事务仍以 COMMIT 或 ROLLBACK 语句显式完成。（如 UPDATE/INSERT/DELETE） n自动提交模式是 Microsoft SQL Server 的默认事务管理模式。 5.1.1 事务 (续) 5.1.2 事务的ACID特性 n事务的ACID特性： 原子性(Atomicity) 一致性(Consistency) 隔离性(Isolation) 持续性(Durability) 事务是并发控制和恢复的基本单位。 保证事务ACID特性是事务处理的重要任务。 5.1.2事务的ACID特性 (续) 原子性(Atomicity)： 事务中包含的所有操作要么全做，要么 全不做 原子性由恢复机制实现 5.1.2事务的ACID特性(续) 一致性(Consistency) 事务的隔离执行必须保证数据库的一致性 事务开始前，数据库处于一致性的状态 ；事务结束后，数据库必须仍处于一致性状态 数据库的一致性状态，由并发控制机制 实现 如银行转帐，转帐前后两个帐户金额之 和应保持不变 5.1.2事务的ACID特性(续) 隔离性(Isolation) 一个事务的执行不能被其他事务干扰。 系统必须保证事务不受其它并发执行事务 的影响 对任何一对事务T1，T2，在T1看来，T2 要么在T1开始之前已经结束，要么在T1完成之 后再开始执行 隔离性通过并发控制机制实现 持久性(Durability) 也称为永久性，指一个事务一旦 提交之后，它对数据库的影响必须是永 久的 系统发生故障不能改变事务的持 久性 持久性通过恢复机制实现 5.1.2事务的ACID特性(续) 5.1.3事务调度 n事务的调度 事务的执行顺序称为一个调度，表示事务的指令在系统中执行的 时间顺序 一组事务的调度必须保证 n包含了所有事务的操作指令 n一个事务中指令的顺序必须保持不变 n调度可以分为串行调度和并行调度两种 串行调度 n在串行调度中，属于同一事务的指令紧挨在一起 n对于有n个事务的事务组，可以有n！个有效调度 并行调度 n在并行调度中，来自不同事务的指令可以交叉执行 n当并行调度等价于某个串行调度时，则称它是正确的 5.1.3事务调度 n并行与串行的对比：、 并行调度可以使事务并发执行，以提高系统的吞 吐量，但可能会破坏数据库的一致性； 串行调度导致时延，效率低。 调度的核心问题应该在保证一致性的前提下最大 限度地提高并发度 5.2并发操作 n并发操作： 当多个用户同时存取数据库就会产生对数据库 的并发操作。 并发操作打破了事务一个一个执行的顺序，会 破坏事务的ACID特性，从而会使数据库处于数据 不一致性状态。 为了充分利用系统资源，发挥数据库共享资 源的特点，应该允许多个事务并行地执行。 5.2并发操作(续) 并发操作带来的数据不一致性: n考虑飞机订票系统中的一个活动序列： 甲售票点(甲事务)读出某航班的机票余额A， 假设A为16； 乙售票点(乙事务)读出同一航班的机票余额A ，也为16； 甲售票点卖出一张机票，修改余额A=A-1， 所以A为15，把A写回数据库； 乙售票点也卖出一张机票，修改余额A=A-1 ，所以A为15，把A写回数据库； 5.3并发控制技术 n为了保证数据一致性，DBMS必须提供并发控 制机制，对并发操作进行正确的调度。并发控 制机制是衡量一个数据库管理系统性能的重要 标志之一。 n并发控制就是用正确的方式调度并发操作，使 一个用户事务的执行不受其他事务的干扰，从 而避免造成数据的不一致性。 n并发控制的主要技术是 封锁（Locking） 5.3并发控制技术 n封锁 n并发调度的可串行性 n两段锁协议 n封锁的粒度 5.3.1封锁 n封锁： 所谓封锁就是事务T在对某个数据对象例 如表、记录等操作之前，先向系统发出请求 ，对其加锁。加锁后事务T就对该数据对象 有了一定的控制，在事务T释放它的锁之前 ，其他的事务不能更新此数据对象。 n基本的封锁类型： 排它锁(Exclusive Locks, 简称X锁) 共享锁(Share Locks, 简称S锁) 5.3.1封锁 排它锁(Exclusive Locks, 简称X锁) 也称为写锁，若事务T给对象A加上X锁后 ，则只允许T读取和修改A，其它事务都不能再 对A加任何类型锁，直到T释放A上的锁。可以 保证X锁释放之前不能再读取和修改A 共享锁(Share Locks, 简称S锁) 又称读锁，事务T给对象A加上S锁后，事务 T可以读取但不能修改A；其他事务只能对A加 S锁，但不能加X锁，直到事务T释放S锁。 5.3.2并发调度的可串行性 n可串行化调度： 多个事务的并发执行是正确的，当且仅当其结果 与按某一次序串行地执行它们时的结果相同，我们 称这种调度策略为可串行化的调度。 串行性调度策略是一种正确的高度策略，因为他 不会将数据库置于不一致状态。 n可串行性： 是并发事务正确性的准则。按这个准则规定，一 个给定的并发调度，当且仅当它是可串行化的，才 认为是正确调度。目前DBMS普遍采用封锁方法实 现并发操作调度的可串行性。 5.3.3两段锁协议 n两段锁协议： 是指所有事务必须分两个阶段对数据项加锁和 解锁 第一阶段（获得封锁）：在对任何数据进行读、 写操作之前，首先要申请并获得对该数据的封锁， 但不能释放任何锁； 第二阶段（释放封锁）：事务可以释放任何数据 项上的任何类型的锁，但不能再申请任何锁。 事务遵守两段协议是可串行化调度的充分条件， 而不是必要条件 5.3.4封锁的粒度 n封锁粒度： 封锁对象的大小称为封锁粒度。封锁对象可以是 逻辑单元，也可以是物理单元。 n 封锁对象（以关系数据库为例）： 逻辑单元：属性值、属性值的集合、元组、关系 、索引项、整个索引直至整个数据库 物理单元：页（数据页或索引页）、块等。 5.3.4封锁的粒度 n封锁粒度与系统的并发度和并发控制的开销密 切相关 n封锁粒度越大，数据库能够被封锁的单元就越 少，并发度就越小，系统开销就越小；反之， 封锁粒度越小，并发度越高，系统的开销越大 。 n选择封锁粒度时要考虑封锁开销和并发度两个 因素。 补充：在企业管理器中查看锁 n在企业管理器目录树下的 管理当前活动锁进程 ID或锁进程对象 中可以查看当前活动的锁。 n在快捷菜单中我们可以展开相应的锁并查看其属性 ；在属性面板中可以刷新或杀死进程。 n在T-SQL中可使用KILL SPID （KILL 52）来结束 当前锁进程。 nSP_LOCK命令来查看所有锁。(sp_lock 或sp_lock 52) 补充：在企业管理器中查看锁 n死锁：当两个或多个用户同时使用一个资源，并 且每一方都想利用他人的资源而不愿放弃自己的 资源时，即在等对方释放资源，就会造成死锁。 n解决方法：“死一个比两个都死要好”。即杀死其 中一个进程。 5.4数据库系统的故障种类（四类） n事务内部的故障 指事务没有达到预期的终点，数据库处于不正确的状态 。 n系统故障 指造成系统停止运转的任何事件，使得系统要重 新启动。例如，特定类型的硬件错误（CPU故障）、 操作系统故障、DBMS代码错误、突然停电 n介质故障 指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁 场干扰等。 n计算机病毒 5.4数据库系统的故障种类（四类） n对数据库的影响大体分为两种类型：一是数据库 本身被破坏；二是数据库本身没有破坏，但由于 事务的运行被非正常终止造成数据可能不正确。 5.5数据库恢复与实现技术 n恢复机制涉及的两个问题是：如何建立冗余数据 ；二是如何利用这些冗余数据实施数据库恢复。 n数据库恢复技术主要有以下两种： 数据转储 登记日志文件 n数据库恢复： 数据库的恢复就是保证把数据库从错误状态 恢复到某一已知的正确状态。 5.5.1.1数据转储 n转储：所谓转储即DBA定期地将整个数据库复 制到磁带或另一个磁盘上保存起来的过程。这些 备用的数据文本称为后备副本或后援副本。 n后备副本只能将数据库恢复到转储时的状态，若 要恢复到故障发生时的状态，必须重新运行转储 后的所有更新事务。 5.5.1.1数据转储 n转储分类： 按转储状态分类：静态转储和动态转储； 静态转储是在系统中无运行事务时进行转储操作 ，即转储期间不允许对数据库的任何存取、修改活动 。 动态转储是指转储期间对数据库进行存取或修改 ，即转储和用户事务可以并发执行。 按转储方式分类：海量转储和增量转储。 海量转储是指每次转储全部数据库 增量转储则指每次只转储上次转储后更新过的数 据。 5.5.1.1数据转储 正常运行 恢复 TaTb 转储运行事务 Tf 重装后备副本重新运行事务 转储和恢复 5.5.1.2登记日志文件 n日志文件： 日志文件是记录事务对数据库的更新操作，以备用 来进行事务故障恢复和系统故障恢复，并协助后备副本 进行介质故障恢复的文件。 n日志文件的两种格式： 以记录为单位的日志文件 以数据块为单位的日志文件 5.5.1.2登记日志文件 n以记录为单位的日志文件内容： 各个事务的开始标记 各个事务的结束标记 各个事务的所有更新操作 每个事务的开始标记、结束标记和每个更新操作 构成日志文件中的一个日志记录。 5.5.1.2登记日志文件 n每个日志记录的主要内容： 事务标识（标明哪个事务） 操作的类型（插入、删除或修改） 操作对象（记录内部标识） 更新前数据的旧值 更新后数据的新值 5.5.1.2登记日志文件(续) n事务故障恢复和系统故障必须用日志文件。 n登记日志文件时必须遵循两条原则： 登记的次序严格按发生事务执行的时间次序。 必须先写日志文件，后写数据库。 5.6恢复策略（三种） n事务故障的恢复 n系统故障的恢复 n介质故障的恢复 5.6.1事务故障的恢复 n事务故障：是指事务在运行至正常终止前被终 止 n恢复子系统应利用日志文件撤销（UNDO）此 事务已对数据库进行的修改。 n事务故障的恢复是由系统自动完成的，对用户 是透明的。 5.6.1事务故障的恢复 n事务故障的恢复步骤： 反向扫描日志文件（即从最后向前扫描日志 文件），查找该事务的更新操作。 对该事务的更新操作执行逆操作。 继续反向扫描日志文件，查找该事务的其他 更新操作，并做同样处理。 如此处理下去，直至读到此事务的开始标记 ，事务故障恢复就完成了。 5.6.2系统故障的恢复 n系统故障的原因：一是未完成的事务对数据库的更 新可以已写入数据库；二是已提交事务对数据库的 更新可能还留在缓冲区没来得及写入数据库。 n恢复操作就是要撤消故障发生时未完成的事务，重 做已完成的事务。 5.6.2系统故障的恢复 n系统故障的恢复步骤： 正向扫描日志文件（即从头扫描日志文件） ，找出在故障发生前已经提交的事务，将其事 务标识记入重做（REDO）队列。同时找出故 障发生时尚未完成的事务，将其事务标识记入 撤销（UNDO）队列。(注意区别P116) 对撤销（UNDO）队列中的各个事务进行撤 销处理。 对重做（REDO）队列中的各个事务进行重 做处理。 5.6.3介质故障的恢复 n介质故障发生后，磁盘上的物理数据和日志文 件被破坏，方法是重装数据库，然后生做已完 成的事务。 n介质故障需要DBA的介入。 n介质故障的恢复步骤： 装入最新的数据库后备副本，使数据库恢复到 最近一次转储时的一致性状态。 装入相应的日志文件副本（转储结束时刻的日 志文件副本），重做已完成的事务。 5.7数据库镜像 n数据库镜像主要用于数据库恢复。 n将整个数据库或其中的关键数据复制到另一个磁 盘上，由DBMS自动保证镜像数据与主数据的一 致性。 n用户往往只选择对关键数据和日志文件镜像，而 不是对整个数据库进行镜像。