数据库恢复技术_2

《数据库恢复技术_2》由会员分享，可在线阅读，更多相关《数据库恢复技术_2（48页珍藏版）》请在金锄头文库上搜索。

1、1,2019年4月23日星期二,数据库原理及应用 第6章 数据库恢复,2,本章内容,3,产生不一致的结果 调价：故障可能使部分价格调整而另一部分价格没有调整。 并发执行的错误 并行执行应用程序可以提高性能 但可能数据相互覆盖 例如：程序1将A提价10，程序2将A涨价10元。 何时更新数据库 读数据库：将数据库中的数据先从磁盘读入内存，然后再将值赋予一个变量。 写数据库：先将变量的值写入内存，然后再由内存写入磁盘。 减少磁盘I/O操作与防止数据不一致的权衡（内存中数据的存放时间）,事务,问题提出,4,事务,事务状态,5,事务的显式定义 BEGIN TRANSACTION BEGIN TRANSA

2、CTION SQL 语句1 SQL 语句1 SQL 语句2 SQL 语句2 COMMIT ROLLBACK END TRANSACTION END TRANSACTION 没有显式地定义事务时，DBMS按缺省为自动划分事务,事务,定义,6,原子性（Atomicity） 事务的所有操作在数据库中要么全部正确反映，要么全部不反映。 解决不一致问题。 在系统崩溃后，DBMS将恢复或撤销系统崩溃时处于活动状态的事务对数据库产生的影响，从而保证事务的原子性。 事务原子性由事务管理部件（Transaction-Management Component）处理。 一致性（Consistency） 是指当事务完

3、成时，必须使所有数据都具有一致的状态。 主要由应用开发人员来确保。,事务,特性（ACID）,7,隔离性（Isolation） 当多个事务并发执行时，一个事务的执行不能被其他事务干扰。 解决前面提到的并发执行带来的错误问题。 由于性能的原因，需要对事务进行交叉调度，但交错调度的效果应该和某个串行调度的结果是一致的。 隔离性通过数据库系统中的并发控制部件（Concurrency-Control Component）处理。 持续性（Durability） 一个事务一旦提交，它对数据库中数据的改变应该是永久性的，即使系统可能出现故障。 持续性由数据库系统中的恢复管理部件（Recovery-Manage

4、ment Component）的软件部件负责。,事务,特性（ACID）,8,本章内容,9,数据库系统对付故障的两种措施 尽可能提高系统的可靠性； 在系统发生故障后，把数据库恢复到一致状态。 恢复机制涉及两个关键问题 如何建立冗余数据 如何利用冗余数据实施数据库恢复 恢复技术是衡量数据库管理系统优劣的重要指标,恢复概述,10,本章内容,11,恢复机制常用的技术 记录日志文件 数据转储,恢复实现,12,日志是DBMS用来记录事务对数据库的更新操作的文件，是日志记录的序列 日志记录描述内容主要包括： 事务标识符:执行写操作事务的唯一标识符。 数据项标识符:事务操作对象的唯一标识符。 前像（BI）:更

5、新前数据的旧值。 后像（AI）:更新后数据的新值。 日志记录形式包括： ：表示事务T已开始。 ：表示事务T已提交。 ：表示事务T不能成功完成，已中止。 ：表示事务T对数据项X执行写操作。写之前的旧值为V1，写之后的新值为V2。,恢复实现,日志,日志内容,13,日志要求 每次事务执行写操作，必须在数据库修改前建立此次写操作的日志记录 日志必须存储在稳定存储器上 稳定存储器中的日志记录顺序必须与写入日志缓冲区中的日志记录顺序完全一样（块写） 先写日志规则 在主存中的数据块输出到数据库前，所有与该数据块中数据有关的日志记录必须已输出到稳定存储器上,恢复实现,日志,日志规则,14,事务的执行时，后像（

6、AI）在事务提交后才写入数据库 日志中记录所有的数据库修改 一个事务的所有写操作延迟到事务的操作结束时才执行，以保证事务的原子性。 事务恢复 忽略未完成的事务；重复已提交事务的影响 恢复过程Redo(Ti)：将事务i更新的所有数据项的值设为新值 简化日志内容结构 日志记录：事务对数据项执行写操作，写入新值V1,恢复实现,日志,后像后写,事务T的执行步骤 在T开始执行前，向日志中写入记录 T的一次write（X）操作导致向日志中写入一条新记录 最后，当T全部操作结束，向日志中写入记录,15,举例：后像后写 药品价格调整：设T1事务中，药品A上调10%，药品B下浮5%。,恢复实现,日志,后像后写,

7、16,恢复管理器执行步骤： 从后向前扫描日志，将提交的事务放入队列redo-list。 从前往后扫描日志。对遇到的每一记录: 如果T不是redo-list中的事务，则什么也不做。 如果T是redo-list中的事务，则为数据项X写入值V1。 对每个未完成的事务，在日志中写入一个记录并刷新日志。,恢复实现,日志,后像后写,17,恢复管理器对故障发生在不同时刻的不同处理,恢复实现,日志,后像后写,REDO,再次REDO,若 在磁盘，同(C),若 不在磁盘，同(a),18,后像前写：后像（AI）在事务提交前完全写入数据库 在日志中记录所有的数据库修改，一个事务的所有写操作在事务提交前已写入磁盘 在恢

8、复时忽略已提交的事务；撤销未完成事务的影响。 执行规则： 日志先写：如果事务T改变了数据项X，则记录变化的日志记录必须在数据项的新值写到磁盘前写入稳定的存储器； 如果事务提交，则日志记录必须在事务改变的所有数据项的新值写入到磁盘后再写入稳定的存储器，但应尽快。,恢复实现,日志,后像前写,事务T的执行步骤： 在T开始执行前，向日志中写入记录 T的一次write（X）操作导致向日志中写入一条新记录 当T全部操作结束，被改变的所有数据项已写入磁盘后向日志中写入记录。,19,事务恢复过程 Undo（i）：将事务i更新的所有数据项的值设为旧值。 简化日志记录内容：省去新值字段 日志记录表示：事务对数据项

9、执行写操作，写前的旧值为V1。,恢复实现,日志,后像前写,20,恢复管理器执行步骤 首先对日志文件从后向前进行扫描，将有记录的事务放入redo-list队列。 然后对日志文件从后向前进行扫描 对遇到的每一个记录，若事务T在redo-list队列中，则恢复管理器什么都不做 对遇到的每一个记录，若事务T不在redo-list队列中，则恢复管理器将数据项X在数据库中的值改为旧值V1。,恢复实现,日志,后像前写,21,恢复管理器对故障发生在不同时刻的不同处理,恢复实现,日志,后像前写,若在磁盘，NO ACTION 若不在磁盘，UNDO 补,UNDO,UNDO,UNDO,22,后像前后写：后像（AI）在

10、事务提交前后写入数据库 被修改数据项写入磁盘的时间可以在日志记录之前进行，也可以放在之后进行 写入的更新日志记录由个部分组成。日志记录表示：事务对数据项执行写操作，写前的旧值为V1，写后的新值为V2 执行规则 日志先写被更新数据项写入磁盘前，更新记录必须已写到稳定存储器上。 恢复过程 Undo (Ti)：将未提交事务Ti更新的所有数据项的值设为旧值。 Redo (Ti)：将已提交事务Ti更新的所有数据项的值设为新值。,恢复实现,日志,后像前后写,23,恢复管理器执行步骤 首先对日志文件从后向前进行扫描，将有记录和没有记录的事务分别放入两个队列：redo-list队列，undo-list队列 从

11、前向后再次扫描日志记录，重新执行redo-list队列中的事务。 从后向前再次扫描日志记录，撤销undo-list队列中的事务。,恢复实现,日志,后像前后写,24,恢复管理器对故障发生在不同时刻的不同处理,恢复实现,日志,后像前后写,UNDO,UNDO,UNDO 或REDO,25,等幂操作 多次执行与执行一次的效果是完全相同的。 无论回滚（Undo）操作还是重做（Redo）操作，恢复的步骤都是等幂的。 当系统从上一次崩溃中恢复时再次发生崩溃，恢复机制仍可再次重复恢复过程，前一次恢复过程中是否已将数据项的值更新为旧值或新值是无关紧要的。,恢复实现,日志,等幂操作,26,利用日志进行数据库恢复时，

12、恢复管理器必须检查日志，确定哪些事务需要REDO，哪些事务需要UNDO。一般来说，需要搜索整个日志才能做出决定。 搜索整个日志的困难 搜索整个日志将耗费大量的时间。 很多需要REDO处理的事务其更新已经写入数据库，重新执行这些操作会浪费大量的时间，使恢复过程变得更长。 解决办法 系统定期或不定期地建立检查点（CheckPoint），保存数据库的状态。,恢复实现,日志,检查点,27,创建检查点方法 提交一致性检查点 高速缓存一致性检查点 模糊一致性检查点,恢复实现,日志,检查点,28,提交一致性检查点 新的事务不能开始直到检查点完成。 现有的事务继续执行直到提交或中止，并且相关日志都写入稳定存储

13、器。 将当前日志缓冲区中的日志记录写回稳定存储器中的日志文件。 将日志记录写入稳定存储器。检查点操作完成。,恢复实现,日志,检查点,29,高速缓存一致性检查点 新的事务不能开始直到检查点完成。 已存在的事务不允许执行新的更新操作，如写缓冲块或写日志记录。 将当前日志缓冲区中的日志记录写回稳定存储器中的日志文件。 将当前数据缓冲区中的所有数据记录写入磁盘。 将日志记录写入稳定存储器，其中L是所有活动事务的列表。,恢复实现,日志,检查点,30,用户等待问题 高速缓存一致性检查点只需将所有当前数据缓冲区中的数据记录写入磁盘，而无需等待事务的提交，这相对于提交一致性检查点而言是一个提高。 但在这个过程

14、中，所有事务不能执行动作，对于用户而言也就是需要等待。 模糊一致性检查点 允许事务在记录写入日志后但在修改过的缓存块写到磁盘前做更新。 系统将最后一个完善检查点记录在日志中的位置存在磁盘的固定位置last-checkpoint 系统在写入记录时不更新改信息，而是在写记录前，创建所有修改过的缓冲块的列表。 只有所有该列表中的缓冲块都输出到磁盘上以后，last-checkpoint信息才会更新。,恢复实现,日志,检查点,31,DBA定期地将整个数据库复制到某种存储介质（如磁带、磁盘、光盘等）上保存起来的过程。 备用的数据文本称为后备副本或后援副本。 数据转储是数据库恢复中采用的基本技术。 转储方法

15、分类 静态转储与动态转储 完全转储与增量转储,恢复实现,数据转储,32,在系统中无运行事务时进行转储 转储开始时数据库处于一致性状态 转储期间不允许对数据库的任何存取、修改活动 优点：实现简单 缺点：降低了数据库的可用性 转储必须等用户事务结束 新的事务必须等转储结束,恢复实现,数据转储,静态转储,33,转储操作与用户事务并发进行 转储期间允许对数据库进行存取或修改 优点 不用等待正在运行的用户事务结束 不会影响新事务的运行 缺点 不能保证副本中的数据正确有效 利用动态转储得到的副本进行故障恢复 需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件 后备副本加上日志文件才能把数据库

16、恢复到某一时刻的正确状态,恢复实现,数据转储,动态转储,34,完全转储: 每次转储全部数据库 增量转储: 只转储上次转储后更新过的数据 完全转储与增量转储比较 从恢复角度看，使用完全转储得到的后备副本进行恢复往往更方便 但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效,恢复实现,数据转储,完全与增量转储,35,本章内容,36,事务故障 逻辑错误：事务由于内部条件（如非法输入、溢出等）无法继续正常执行。 系统错误：系统进入一种不良状态（如死锁），事务无法继续正常执行。 事务故障使得事务无法达到预期的终点，数据库可能处于不一致的状态。恢复机制强行回滚该事务，撤销该事务对数据库做的任何修改。 系统故障 包括硬件故障、数据库软件或操作系统的漏洞造成的系统停止运转。它导致系统易失性存储器中的内容丢失，事务处理停止，但非易失性存储器中的内容不会受到破坏。 介质故障 在数据传送操作过程中由于磁头损坏或故障