J第7章数据库恢复技术

数据库系统概论AnIntroductiontoDatabaseSystem第七章数据库恢复技术1第七章数据库恢复技术7.1事务的根本概念7.2数据库恢复概述7.3故障的种类7.4恢复的实现技术7.5恢复策略27.1.1事务的根本概念事务处理技术包括数据库恢复和并发控制技术。一、什么是事务?事务(Transaction)是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位DBMS将事务看作数据库运行中的一个逻辑工作单位，由DBMS的事务管理子系统负责事务的控制和管理。事务是恢复和并发控制的根本单位3二、如何定义事务显式定义方式

BEGINTRANSACTIONBEGINTRANSACTIONSQL语句1SQL语句1SQL语句2SQL语句2。。。。。。。。。。COMMITROLLBACK隐式方式当用户没有显式地定义事务时，DBMS按缺省规定自动划分事务4三、事务结束COMMIT事务正常结束提交事务的所有操作〔读+更新〕事务中所有对数据库的更新永久生效ROLLBACK事务异常终止事务运行的过程中发生了故障，不能继续执行回滚事务的所有更新操作事务回滚到开始时的状态57.1.2实例[例1]将学生-选课数据库中，英语课的课程编号由1156修改为2256。所涉及的关系：Course(Cno,Cname,Cpno,Ccredit)SC(Sno,Cno,Grade)根据参照完整性约束，应将两表中的1156都改为2256。要将修改两个表的两个SQL语句定义成一个事务。DBMS对这两个语句要么都执行，要不都不执行。6定义事务如下：BEGINTRANSACTIONUPDATECourseSETCno=‘2256’WHERECno=‘1156’;UPDATESCSETCno=‘2256’WHERECno=‘1156’;COMMIT7[例2]在银行应用中，将账户A的1万元

转移到B账户中定义一个事务，该事务包括两个操作：A=A-1万B=B+1万这两个操作要么全做，要么全不做设有表：存款余额表(用户标识，余额)在数据库中为：Account(CID,Balance)8[例2]定义事务如下：EXECSQLBEGINETRANSACTIONEXECSQLUPDATEAccountSETBalance=Balance+10000WHERECID=‘B’;EXECSQLSELECTBalanceINTO:C_Balance/*取A帐户余额到变量中*/FROMAccountWHERECID=‘A’;9IfC_Balance<10000/*如果余额不够，*/Then{printf(“余额缺乏”),EXECSQLROLLBACK;/*回到开始状态，撤消给B帐户的1万元*/}Else{EXECSQLUPDATEAccount/*余额够，帐户A-1万*/SETBalance=Balance-10000WHERECID=‘A’;EXECSQLCOMMIT;}事务和程序是两个概念在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序一个应用程序通常包含多个事务107.1.3事务的特性事务有4个特性(简称ACID特性)：原子性〔Atomicity〕一致性〔Consistency〕隔离性〔Isolation〕持续性〔Durability〕111.原子性原子性指：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做122.一致性事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态一致性状态：数据库中只包含成功事务提交的结果不一致状态：如果数据库运行中发生故障，有些事务还没完成就被迫中断，事务对数据库的修改有一局部已写入数据表，这时数据库就处于不一致状态。13一致性与原子性是密切相关的。银行转帐：从帐号A中取出1万元，存入帐号B。定义一个事务，该事务包括两个操作这两个操作要么全做，要么全不做(原子性)全做或者全不做(原子性)，数据库都处于一致性状态。如果只做一个操作，数据库就处于不一致性状态。

B=B+1

A=A-1BA143.隔离性对多个事务并发执行而言，一个事务的执行不能被其他事务干扰。一个事务内部的操作及使用的数据对其他并发事务是隔离的并发执行的各个事务之间不能互相干扰15下例中，事务T1的修改被事务T2覆盖了！所以T1与T2不是隔离的,是互相影响的.

读A=16

A←读出的A-3写回A=13①读A=16

②

③A←A-1写回A=15④T2T1164.持续性持续性也称永久性一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。17事务的特性保证事务ACID特性是事务管理子系统的重要任务可能破坏事务ACID特性的因素:〔1〕多个事务并行运行时，不同事务的操作交叉执行〔2〕事务在运行过程中被强行终止对于〔1〕情况，DBMS必须保证多个事务的交叉运行，不影响这些事务的原子性。对于〔2〕情况，DBMS必须保证被迫终止的事务对数据库和其他事务没有影响。这些就是DBMS的恢复机制和并发控制机制的责任。187.2数据库恢复概述故障是不可防止的计算机硬件故障系统软件和应用软件的错误操作员的失误恶意的破坏故障的影响轻那么造成运行事务非正常中断重那么破坏数据库,使数据丧失因此,DBMS必须具有将数据库从错误状态恢复到某一的正确〔一致〕状态的功能。这就是数据库恢复功能。19数据库恢复概述〔续〕数据库管理系统对故障的对策DBMS提供恢复子系统(是DBMS的重要局部)它保证故障发生后，能把数据库中的数据从错误状态恢复到某种逻辑一致的状态保证事务的〔四个〕ACID特性。恢复技术是衡量系统优劣的重要指标207.3

故障的种类数据库系统可能发生的故障：事务故障系统故障介质故障计算机病毒21、事务内部故障什么是事务故障某个事务在运行过程中由于种种原因未运行至正常终点就终止了造成事务非正常终止的原因有的可以通过事务程序本身发现，如[例2]中，帐户A的余额缺乏，那么终止事务的执行，让事务回滚，撤消已做的修改，恢复数据库到正确状态；有的故障是非预期的，不能由事务程序自己来处理。22事务故障的常见原因输入数据有误运算溢出违反了某些完整性限制某些应用程序出错并行事务发生死锁。。。。23事务故障的恢复发生事务故障时，夭折的事务可能已把对数据库的局部修改写回磁盘事务故障的恢复：撤消事务〔UNDO〕强行回滚〔ROLLBACK〕该事务,去除该事务对数据库的所有修改，使得这个事务象根本没有启动过一样247.3.2系统故障什么是系统故障系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。系统故障的常见原因特定类型的硬件错误〔如CPU故障〕突然停电操作系统或DBMS代码错误操作员操作失误25系统故障造成:整个系统的正常运行突然被破坏所有正在运行的事务都非正常终止内存中数据库缓冲区的信息全部丧失外部存储设备上的数据未受影响即,这类故障影响正在运行的所有事务,但不破坏数据库.26系统故障的恢复恢复子系统在系统重新启动时做到:去除尚未完成的事务对数据库的所有修改系统重新启动时，恢复程序要让所有非正常终止的事务回滚,强行撤消〔UNDO〕所有未完成事务277.3.3介质故障系统故障称为软故障，介质故障称为硬故障。硬故障指外存故障。如：硬盘损坏、磁头碰撞、瞬时强磁场干扰等。硬件故障使存储在外存中的数据局部丧失或全部丧失。这类故障将破坏数据库或破坏局部数据库，并影响正在存取这局部数据的事务。介质故障比前两类故障的可能性小得多，但破坏性大得多287.3.4计算机病毒这是人为的故障或破坏，是一种计算机程序这种程序像病毒一样可以繁殖和传播，并造成对计算机系统包括数据库的危害。计算机病毒已成为计算机系统的主要威胁，也是数据库系统的主要威胁。计算机平安工作者已研制了许多防病毒和查、杀病毒的软件。但还没有使计算机终生免疫的“疫苗”。因此数据库一旦被破坏，仍要用恢复技术对数据库进行恢复。29总结各类故障，对数据库的影响有两种可能：一是数据库本身被破坏，二是数据库没有破坏，但数据不正确〔不一致〕，是因为事务的非正常终止造成的。30恢复操作的根本原理恢复操作的根本原理：冗余利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那局部数据尽管恢复操作的根本原理很简单，恢复的实现技术却复杂一个大型数据库产品，恢复子系统的代码要占全部代码的10%以上317.4恢复的实现技术恢复机制涉及的关键问题：1.如何建立冗余数据数据转储〔backup〕登录日志文件〔Logging〕2.如何利用这些冗余数据实施数据库恢复

327.4.1数据转储一、什么是转储二、转储的用途三、转储方法33一、什么是转储转储是指DBA定期地将整个数据库复制到另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副本。二、转储的用途当数据库遭到破坏时，可以将后备副本重新装入。但重装后备副本只能将数据库恢复到转储时的状态。要恢复到故障发生时的状态，需要重新运行自转储以后的所有更新事务。34例如：

故障发生点

转储

运行事务↓正常运行─┼───────┼─────────────TaTbTf

重装后备副本

重新运行事务恢复

─┼───────┴－－－－－－－－→此处停止运行事务，开始转储。转储完毕，得到Tb时刻的数据库副本。然后继续运行事务。重装后备副本，将数据恢复到Tb时刻的状态重新运行Tb~Tf时刻的所有更新事务，将数据恢复到故障发生前的状态35三、转储方法转储十分消耗时间和资源,不能频繁进行.DBA应根据数据库使用情况,确定一个适当的转储周期.转储分为：1．静态转储与动态转储2．海量转储与增量转储361．静态转储静态转储是指在系统中无运行事务时进行转储转储开始时数据库处于一致性状态转储期间不允许对数据库做任何存取、修改活动.优点：实现简单，得到的是一致性的数据副本。缺点：降低了数据库的可用性转储必须等用户事务结束新的事务必须等转储结束37利用静态转储副本进行恢复

故障发生点

静态转储

运行事务↓正常运行─┼───────┼─────────────TaTbTf

重装后备副本

恢复

─┼───────┥此处停止运行事务，进行转储。转储完毕，得到Tb时刻的数据库副本。然后继续运行事务。重装后备副本，将数据恢复到Tb时刻的状态382.动态转储转储操作与用户事务并发进行转储期间允许对数据库进行存取或修改优点不用等待正在运行的用户事务结束不会影响新事务的运行缺点不能保证副本中的数据正确有效39例如，动态转储问题

A=100转储─┼───────┼──────┼──────TaTbTc

A=200

运行事务─────────────────┼──

TdTc时刻，将A=100转储到磁盘上。Td时刻，运行的事务，将A改为200可见，转储结束时，副本上的A=100数据已经过时了。因此需要把动态转储期间各事务对数据库的修改活动登记下来40动态转储利用动态转储得到的副本进行故障恢复需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件(LogFile)后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态412．海量转储与增量转储海量转储:每次转储全部数据库增量转储:只转储上次转储后更新过的数据海量转储与增量转储比较从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便但如果数据库很大，事务处理又十分频繁，那么增量转储方式更实用更有效423．转储方法小结转储方法分类

转储状态动态转储静态转储转储方式海量转储动态海量转储静态海量转储增量转储动态增量转储静态增量转储43转储策略应定期进行数据转储，制作后备副本。但转储又是十分消耗时间和资源的，不能频繁进行。DBA应该根据数据库使用情况确定适当的转储周期和转储方法。例：每天晚上进行动态增量转储每周进行一次动态海量转储每月进行一次静态海量转储447.4.2登记日志文件一、日志文件的内容二、日志文件的用途三、登记日志文件的原那么45一、日志文件的内容1.什么是日志文件日志文件(log)是用来记录事务对数据库的更新操作的文件2.日志文件的格式有以下两种：以记录为单位的日志文件以数据块为单位的日志文件46日志文件的内容〔续〕3.日志文件内容主要包括：各个事务的开始标记(BEGINTRANSACTION)各个事务的结束标记(COMMIT或ROLLBACK)各个事务的所有更新操作每个事务的以上内容作为日志文件中的一个日志记录(logrecord)474.基于记录的日志文件每条日志记录的内容主要包括：事务标识〔标明是哪个事务〕操作类型〔插入、删除或修改〕操作对象〔记录内部标识〕更新前数据的旧值〔对插入操作而言，此项为空值〕更新后数据的新值〔对删除操作而言,此项为空值〕485.以数据块为单位的日志文件每条日志记录的内容包括：事务标识〔标明是哪个事务〕更新前数据所在的整个数据块的值〔对插入操作而言，此项为空值〕更新后整个数据块的值〔对删除操作而言,此项为空值〕49二、日志文件的用途日志文件在数据库恢复中起着重要的作用。如：进行事务故障恢复进行系统故障恢复协助后备副本进行介质故障恢复50日志文件的用途〔续〕具体作用：〔1〕事务故障和系统故障恢复必须用日志文件。〔2〕日志文件与静态转储后备副本配合进行介质故障恢复静态转储的数据已是一致性的数据如果静态转储完成后，仍能定期转储日志文件，那么在出现介质故障重装数据副本后，可以利用这些日志文件副本对已完成的事务进行重做处理这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态51日志文件的用途〔续〕

故障发生点

静态转储运行事务↓正常运行─┼──────┼──────────┼──TaTbTf

登记日志文件└───────────┴──

重装后备副本利用日志文件恢复事务继续运行介质故障恢复─────────┴－－－－－─－－－－－－－┴──────

登记日志文件└──────52日志文件的用途〔续〕〔3〕在动态转储方式中建立日志文件，LOGFILE+动态转储后备副本进行有效的介质故障恢复动态转储数据库，同时转储同一时点的日志文件后备副本与该日志文件结合起来才能将数据库恢复到一致性状态。利用这些日志文件副本进一步恢复事务，防止重新运行事务程序。53利用动态转储副本进行恢复

Ta运行事务TbTf

动态转储

运行事务

故障发生点正常运行─┼───────┼─────────────登记日志文件登记新日志文件─────────┼─────────────

转储日志文件

重装后备副本+用转储的日志文件恢复恢复到一

━━━━━━┥致性状态54三、登记日志文件的原那么为保证数据库是可恢复的，登记日志文件时必须遵循两条原那么登记的次序严格按并发事务执行的时间次序必须先写日志文件，后写数据库先写日志文件操作：把表示对数据库修改的日志记录写到日志文件中后写数据库操作：把对数据的修改写到数据库中55登记日志文件的原那么〔续〕为什么要先写日志文件写数据库和写日志文件是两个不同的操作在这两个操作之间可能发生故障如果先写了数据库修改，而在日志文件中没有登记下这个修改，那么以后就无法恢复这个修改了如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的撤消〔UNDO〕操作，并不会影响数据库的正确性567.5恢复策略7.5.1事务故障的恢复7.5.2系统故障的恢复7.5.3介质故障的恢复577.5.1事务故障的恢复事务故障：是指事务在运行至正常终止点之前被终止。恢复方法由恢复子系统利用日志文件撤消〔UNDO〕此事务已对数据库进行的修改事务故障的恢复由系统自动完成，不需要用户干预58DBMS执行事务故障的恢复步骤1.反向扫描日志文件〔即从最后向前扫描日志文件〕，查找该事务的更新操作。2.对该事务的更新操作执行逆操作。即，将日志记录中“更新前的值”写入数据库。登记的插入操作，“更新前的值”为空，那么恢复时相当于做删除操作登记的删除操作，“更新后的值”为空，那么恢复时相当于做插入操作假设登记的是修改操作，那么用更新前的值代替更新后的值59事务故障的恢复步骤3.继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。4.如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。60例:如图要对事务Ti进行恢复,

即撤消(UNDO)该事务对数据库的修改步骤如下:(1)从日志文件尾反向扫描,找到Ti-insert记录,从中知道Ti插入了哪个记录,将其删除.(2)再接着往回扫描,找到Ti-update记录,从中知道Ti修改了哪个记录,将其用修改前的值替换回去.(3)再接着往回找到Ti-delete记录,从中知道Ti删除了哪个记录,将其插入.(4)再接着往回扫描,找到各个Ti的操作,执行UNDO操作直到Ti-begin为止.Ti-begin…Ti-delete…Ti-update…Ti-insert…日志文件尾617.5.2系统故障的恢复系统故障造成数据库不一致状态的原因:一些未完成事务对数据库的更新已写入数据库一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库恢复方法1.Undo〔撤消〕故障发生时未完成的事务2.Redo〔重做〕已完成的事务系统故障的恢复由系统在重新启动时自动完成，不需要用户干预62系统故障的恢复步骤1. 正向扫描日志文件〔即从前头扫描日志文件〕将在故障发生前已经提交的事务记入Redo队列:T1,T3,T8…..(这些事务既有BEGINTRANSACTION记录,也有COMMIT记录)将故障发生时尚未完成的事务记入Undo队列:T2,T4,T5,T6,T7,T9…...…..(这些事务有BEGINTRANSACTION记录,无COMMIT记录)63系统故障的恢复步骤2.对Undo队列事务进行UNDO(撤消)处理反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作：将“更新前的值”写入数据库。3.对Redo队列事务进行REDO(重做)处理正向扫描日志文件，对每个REDO事务重新执行登记的操作，将“更新后的值”写入数据库。647.5.3介质故障的恢复发生介质故障后,磁盘上的物理数据和日志文件被破坏。恢复的方法是:1.重装数据库，使数据库恢复到一致性状态2.重做已完成的事务657.5.3介质故障的恢复具体恢复步骤:1.装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态。对于静态转储的数据库副本，装入后数据库即处于一致性状态对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用与恢复系统故障相同的方法〔即REDO+UNDO〕，才能将数据库恢复到一致性状态。66利用静态转储副本将数据库恢复到一致性状态

故障发生点

静态转储

运行事务