7事务处理技术

第七章事务处理技术数据库恢复技术事务－用户定义的一个数据库操作序列，这些操作要么都做要么都不做，是不可分割的。事务是DBMS中的基本执行单位；事务是恢复和并发控制的基本单位如何定义事务显式定义方式BEGINTRANSACTIONBEGINTRANSACTIONSQL语句1SQL语句1SQL语句2SQL语句2…………COMMITROLLBACK隐式方式–当用户没有显式地定义事务时，–DBMS按缺省规定自动划分事务COMMIT–事务正常结束–提交事务的所有操作（读+更新）–事务中所有对数据库的更新永久生效ROLLBACK–事务异常终止–事务运行的过程中发生了故障，不能继续执行–回滚事务的所有更新操作–事务滚回到开始时的状态事务的特性ACID特性A(原子性)－不可分割的逻辑工作单位。C(一致性)－事务要保证数据库从一个一致性状态到另一个一致性状态。I(隔离性)－事务内部的操作对其他事务是隔离的。D(持久性)－事务COMMIT后，对数据库的改变的持久性。1.原子性事务是数据库的逻辑工作单位–事务中包括的诸操作要么都做，要么都不做2.一致性事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性状态：数据库中只包含成功事务提交的结果不一致状态：数据库中包含失败事务的结果一致性与原子性银行转帐：从帐号A中取出一万元，存入帐号B。–定义一个事务，该事务包括两个操作–这两个操作要么全做，要么全不做全做或者全不做，数据库都处于一致性状态。如果只做一个操作，数据库就处于不一致性状态。B=B+1A=A-1BA3.隔离性对并发执行而言一个事务的执行不能被其他事务干扰一个事务内部的操作及使用的数据对其他并发事务是隔离的并发执行的各个事务之间不能互相干扰T1的修改被T2覆盖了！读A=16A←A-3写回A=13①读A=16②③A←A-1写回A=15④T2T14.持续性持续性也称永久性（Permanence）–一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。–接下来的其他操作或故障不应该对其执行结果有任何影响。事务的特性保证事务ACID特性是事务处理的任务破坏事务ACID特性的因素–多个事务并行运行时，不同事务的操作交叉执行–事务在运行过程中被强行停止•在任何情况下，DBMS都应保证事务的ACID性质。正常运行时和发生故障时，都应保证事务的ACID性质。•不但在单个应用运行时应保证事务的ACID性质；而且在多个应用并行运行时，也应保证事务的ACID性质。•保证事务在故障发生时满足ACID性质的措施称为恢复技术。•保证多个事务在并行执行时满足ACID性质的措施称为并发控制技术。•恢复和并发控制是保证事务正确运行的两项基本技术，它们被合称为事务管理。恢复技术概述故障是不可避免的–计算机硬件故障–系统软件和应用软件的错误–操作员的失误–恶意的破坏故障的影响–运行事务非正常中断–破坏数据库数据库管理系统对故障的对策–DBMS提供恢复子系统–保证故障发生后，能把数据库中的数据从错误状态恢复到某种逻辑一致的状态–保证事务ACID恢复技术是衡量系统优劣的重要指标故障的种类1、事务内部故障•事务内部的故障有的是可以通过事务程序本身发现的（见下面转帐事务的例子），有的是非预期的，不能由事务程序处理的。•例如：银行转帐事务，这个事务把一笔金额从一个帐户甲转给另一个帐户乙。BEGINTRANSACTION读帐户甲的余额BALANCE；BALANCE=BALANCE-AMOUNT；AMOUNT为转帐金额）IF（BALANCE〈0）THEN{打印′金额不足，不能转帐′；ROLLBACK；（撤消刚才的修改，恢复事务）}ELSE{读帐户乙的余额BALANCE1；BALANCE1=BALANCE1+AMOUNT；写回BALANCE1；COMMIT；}•上面这个例子所包括的两个更新操作要么全部完成要么全部不做。否则就会使数据库处于不一致状态，例如只把帐户甲的余额减少了而没有把帐户乙的余额增加。•在这段程序中若产生帐户甲余额不足的情况，应用程序可以发现并让事务滚回，撤消已作的修改，恢复数据库到正确状态。•事务内部更多的故障是非预期的，是不能由应用程序处理的。如运算溢出、并发事务发生死锁而被选中撤消该事务、违反了某些完整性限制等。以后，事务故障仅指这类非预期的故障。事务故障的常见原因–输入数据有误–运算溢出–违反了某些完整性限制–某些应用程序出错–并行事务发生死锁–……发生事务故障时，夭折的事务可能已把对数据库的部分修改写回磁盘事务故障的恢复：撤消事务（UNDO）强行回滚（ROLLBACK）该事务清除该事务对数据库的所有修改，使得这个事务象根本没有启动过一样2.系统故障什么是系统故障–整个系统的正常运行突然被破坏–所有正在运行的事务都非正常终止–内存中数据库缓冲区的信息全部丢失–外部存储设备上的数据未受影响系统故障的常见原因操作系统或DBMS代码错误操作员操作失误特定类型的硬件错误（如CPU故障）突然停电系统故障的恢复清除尚未完成的事务对数据库的所有修改–系统重新启动时，恢复程序要强行撤消（UNDO）所有未完成事务将缓冲区中已完成事务提交的结果写入数据库–系统重新启动时，恢复程序需要重做（REDO）所有已提交的事务•发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，从而造成数据库可能处于不正确的状态。•为保证数据一致性，恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤消(UNDO)所有未完成事务。重做(Redo)所有已提交的事务，以将数据库真正恢复到一致状态。3、介质故障•系统故障常称为软故障（SoftCrash），介质故障称为硬故障（HardCrash）。•硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。•这类故障比前两类故障发生的可能性小得多，但破坏性最大。4、计算机病毒•计算机病毒是具有破坏性、可以自我复制的计算机程序。计算机病毒已成为计算机系统的主要威胁，自然也是数据库系统的主要威胁。因此数据库一旦被破坏仍要用恢复技术把数据库加以恢复。•总结各类故障，对数据库的影响有两种可能性。一是数据库本身被破坏。二是数据库没有破坏，但数据可能不正确，这是因为事务的运行被非正常终止造成的。恢复的实现技术1、概述•恢复机制涉及的两个关键问题是：第一，如何建立冗余数据；第二，如何利用这些冗余数据实施数据库恢复。•建立冗余数据最常用的技术是数据备份和登记日志文件。通常在一个数据库系统中，这两种方法是一起使用的。恢复技术大致有下列三种：1.单纯以后备复本为基础的恢复技术；1）周期性的数据库转储；2）增量转储。优点：实现简单，不增加数据库正常运行时的开销。缺点：不能恢复到数据库的最近一致状态。（只能用在小型和不重要的数据库系统）2.以后备复本和运行记录（Log或Journal)为基础的恢复技术；下面将详细介绍这种技术。优点：数据库恢复到最近的一致状态。缺点：实现复杂，运行时需保留运行记录。----大部分商品化DBMS支持这种恢复技术，这是主要的恢复方法。3.基于多复本的恢复技术镜像磁盘系统优点：多复本互为备份，具有独立的失效模式。缺点：增加费用。2、数据库备份•所谓备份即DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副本。•当数据库遭到破坏后可以将后备副本重新装入，但重装后备副本只能将数据库恢复到备份时的状态，要想恢复到故障发生时的状态，必须重新运行自备份以后的所有更新事务。例、在下图中，系统在Ta时刻停止运行事务进行数据库备份，在Tb时刻备份完毕，得到Tb时刻的数据库一致性副本•系统运行到Tf时刻发生故障。为恢复数据库，首先由DBA重装数据库后备副本，将数据库恢复至Tb时刻的状态，然后重新运行自Tb时刻至Tf时刻的所有更新事务，这样就把数据库恢复到故障发生前的一致状态。•备份是十分耗费时间和资源的，不能频繁进行。DBA应该根据数据库的使用情况确定一个适当的备份周期。•备份可分为脱机备份和联机备份两种方式。•脱机备份是在备份过程中数据库系统处于脱机状态，即在备份过程中数据库系统不再接受应用程序的访问，因此，脱机备份又称为静态备份。•联机备份是在备份过程中数据库系统处于联机状态，即在进行备份的同时数据库系统还可接受应用程序的访问。因此，联机备份又称为动态备份。•备份还可以分为海量备份和增量备份两种方式。•海量备份是指每次备份全部数据库。•增量备份则指每次只备份上一次备份后更新过的数据。•从恢复角度看，使用海量备份得到的后备副本进行恢复一般说来会更方便些。但如果数据库很大，事务处理又十分频繁，则增量备份方式更实用更有效。3、数据库日志1)日志文件的格式和内容•日志文件是用来记录事务对数据库的更新操作的文件。•不同数据库系统采用的日志文件格式并不完全一样。概括起来日志文件主要有两种格式：–以记录为单位的日志文件和–以数据块为单位的日志文件•对于以记录为单位的日志文件，日志文件中需要登记的内容包括：•各个事务的开始(BEGINTRANSACTION)标记•各个事务的结束(COMMIT或ROLLBACK)标记•各个事务的所有更新操作•这里每个事务开始的标记、每个事务的结束标记和每个更新操作均作为日志文件中的一个日志记录(logrecord)。•每个日志记录的内容主要包括：•事务标识TID(标明是那个事务)•操作的类型(插入、删除或修改)•操作对象(记录内部标识)•更新前数据的旧值(对插入操作而言，此项为空值)•更新后数据的新值(对删除操作而言,此项为空值)2)日志文件的作用•日志文件在数据库恢复中起着非常重要的作用。可以用来进行事务故障恢复和系统故障恢复，并协助后备副本进行介质故障恢复。•具体地讲：事务故障恢复和系统故障必须用日志文件。•在动态备份方式中必须建立日志文件，后援副本和日志文件综合起来才能有效地恢复数据库。•在静态备份方式中，也可以建立日志文件。•当数据库毁坏后可重新装入后援副本把数据库恢复到备份结束时刻的正确状态，然后利用日志文件，把已完成的事务进行重做处理，对故障发生时尚未完成的事务进行撤消处理。•这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态。3)登记日志文件（logging）•为保证数据库是可恢复的，登记日志文件时必须遵循两条原则：1.登记的次序严格按并发事务执行的时间次序。2.必须先写日志文件，后写数据库。•把对数据的修改写到数据库中和把写表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障，即这两个写操作只完成了一个。如果先写了数据库修改，而在运行记录中没有登记下这个修改，则以后就无法恢复这个修改了。如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性。所以为了安全，一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。这就是所谓的“提前写日志”原则。1.事务故障的恢复•事务故障是指事务在运行至正常终止点前被中止，这时恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改。•事务故障的恢复是由系统自动完成的，对用户是透明的。系统的恢复步骤是：1)反向扫描文件日志(即从最后向前扫描日志文件)，查找该事务的更新操作。2)对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则相当于做删除操作(因此时“更新前的值”为空)。若记录中是删除操作，则做插入操作，若是修改操作，则相当于用修改前值代替修改后值。3)继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。4)如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。2.系统故障的恢复•前面