【数据库习题原理 10】数据库恢复技术

最新推荐文章于 2022-06-15 12:39:19 发布

翙翙Cici

最新推荐文章于 2022-06-15 12:39:19 发布

阅读量1.2k

点赞数 1

分类专栏：数据库系统原理文章标签：数据库 database sql

本文链接：https://blog.csdn.net/weixin_46517035/article/details/122368617

版权

数据库系统原理专栏收录该内容

6 篇文章 1 订阅

订阅专栏

完成本章的学习，你应该能够

–理解事务的概念及ACID特性

–理解事务故障、系统故障、介质故障及计算机病毒发生的原因及导致的后果

–理解备份在数据库恢复中的作用

–深刻理解并掌握日志文件的内容及使用

–熟练掌握事务故障、系统故障和介质故障的数据库恢复策略及步骤

–熟练掌握利用日志文件进行数据库恢复的技术

–掌握使用检查点的数据库恢复技术

–理解数据库镜像在数据库恢复中的作用

事务的基本概念

事务处理技术(Transaction Processing)主要包括数据库恢复技术和并发控制技术，事务是恢复与并发控制的基本单位。

事务：是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。

区分程序：

事务是数据库应用程序的基本逻辑单元。
在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序。
一个程序通常包含多个事务。

定义事务：

BEGIN TRANSACTION; COMMIT; ROLLBACK; SAVEPOINT

在这里插入图片描述
事务的ACID特性：

原子性(Atomicity):
- 事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不错。
一致性(Consistency):
- 事务执行的结果必须是使数据库从一个一致性状态转变到另一个一致性状态。
- 完整性约束的自动检查是实现一致性的一种方法
隔离性(Isolation):
- 一个事务的执行不能被其他事务干扰，即一个事务的内部操作及使用的数据对其它并发事务是隔离的。
持续性/持久性/永久性(Durability):
- 一个事务一旦提交，它对数据库中数据的改变就是永久性的，接下来的其它操作或故障不应该对其执行结果有任何影响。

事务ACID特性可能遭到破坏的因素：

多个事务并行运行时，不同事务的操作交叉执行

DBMS必须保证多个事务的交叉运行不影响这些事务的隔离性
事务中运行过程中被强行终止

DBMS必须保证被强行终止的事务对数据库和其他事务没有任何影响

数据恢复概述

DBMS必须具有数据恢复的功能，即把数据库从错误状态恢复到某一已知正确状态(一致性状态或完整状态)的功能。

故障的种类

事务内部故障

事务故障意味着事务没有达到预期的终点(COMMIT或显式的ROLLBACK)，因此数据库可能处于不正确的状态。

有些可通过事务程序本身发现
更多的是非预期的，不能由应用程序处理
- 运算溢出
- 并发事务发生死锁而被选中撤销该事务
- 违反了某些完整性限制而被终止

事务故障的恢复操作：

事务撤销(UNDO)

系统故障

系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。也称为软故障(soft crash)。

特定类型的硬件错误（如CPU故障）
操作系统故障
DBMS代码错误
系统断电

系统故障特点：

所有运行的事务都非正常终止，但不破坏数据库
内存中数据库缓冲区的信息全部丢失

系统故障的恢复操作：

系统重新启动时，恢复程序让所有非正常终止的事务回滚，强行撤销(UNDO)所有未完成事务。
系统重新启动时，恢复程序重做(REDO)所有已完成的事务。

介质故障

介质故障也称为硬故障(Hard crash)，指外存故障。

发生截止故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障。

磁盘损坏
磁头碰撞
瞬时强磁场干扰

介质故障特点：

破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务
与事务故障和系统故障相比，发生的可能性小，但破坏性最大

计算机病毒

计算机病毒是一种人为的故障或破坏，是一种恶意计算机程序。

计算机病毒特点：

可以繁殖和传播，造成对计算机系统包括数据库的危害。

计算机病毒已成为计算机系统和数据库系统的主要威胁。

小结

各类故障对数据库的影响有两种可能性：

数据库本身被破坏；
数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的。

恢复的基本原理

冗余，即可以利用存储在系统别处的冗余数据来重建数据库中已被破坏或不正确的那部分数据。

恢复的基本原理简单，实现技术细节相当复杂

一个大型数据库产品，恢复子系统的代码要占全部代码的10%以上

恢复的实现技术

涉及的关键问题：

如何建立冗余数据
如何利用这些冗余数据实施数据库恢复

建立冗余数据最常用的技术

数据转储
登记日志文件(logging)

1. 数据转储

数据转储是指数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程。

备用的数据称为后备副本或后援副本(backup)

静态转储

是在系统中无运行事务时进行的转储操作，即转储操作开始的时刻数据库处于一致性状态，在转储期间不允许(或不存在)对数据库的任何存取、修改。
静态转储得到的一定是一个数据一致性的副本
优点：实现简单
缺点：降低了数据库的可用性
- 转储必须等待正运行的用户事务结束
- 新的事务必须等转储结束

动态转储

是指转储期间允许对数据库进行存取或修改，即转储和用户事务可以并发执行
优点：克服了静态转储的缺点，不用等待正在运行的用户事务结束，也不会影响新事务的运行。
缺点：不能保证转储结束后后援副本的数据正确有效

解决方法：

把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件(log file)
后援副本加上日志文件就能把数据库恢复到某一时刻的正确状态

其它分类

转储也可分为海量转储和增量转储。

海量转储是指每次转储全部数据库
增量转储是指每次只转储上一次转储后更新过的数据
海量转储与增量转储比较
- 从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便
- 如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效

Oracle的逻辑备份是用使用Oracle提供的操作系统工具Export、Import将数据库中的数据导出、导入。

2. 登记日志文件

日志文件

是用来记录事务对数据库的更新操作的文件。

日志文件的格式和内容

1、以记录为单位的日志文件

需要登记的内容包括：

各个事务的开始标记(BEGIN TRANSACTION)
各个事务的结束标记(COMMIT或ROLLBACK)
各个事务的所有更新操作

每个日志记录的内容主要包括：

事务标识（标明是哪个事务）
操作的类型（插入、删除或修改）
操作对象（记录内部标识）
更新前数据的旧值（对插入操作而言，此项为空值）
更新后数据的新值（对删除操作而言，此项为空值）

2、以数据块为单位的日志文件

日志记录的内容包括：

事务标识
更新的数据块

（由于将更新前的整个块和更新后的整个块都放入日志文件中，操作类型和操作对象等信息就无需放入日志记录中）

日志文件的作用

用来进行事务故障恢复和系统故障恢复

协助后备副本进行介质故障恢复

日志文件的具体作用

事务故障恢复和系统故障恢复必须用日志文件
在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库
在静态转储方式中，也可以建立日志文件
- 当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态
- 利用日志文件，把已完成的事务进行重做处理
- 对故障发生时尚未完成的事务进行撤销处理
- 不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态

登记日志文件的原则：

登记的次序严格按并发事务执行的时间次序。
必须先写日志文件(把表示这个修改的日式记录写到日志文件中)，后写数据库(把对数据的修改写到数据库中)。

恢复策略

事务故障的恢复

恢复策略：

由恢复子系统利用日志文件撤销（UNDO）此事务已对数据库进行的修改。

事务故障的恢复由系统自动完成，对用户透明。

恢复步骤：

反向扫描日志文件（即从最后向前扫描日志文件），查找该事务的更新操作。
对该事务的更新操作执行逆操作，即将日志文件中“更新前的值”写入数据库。
- 插入操作，“更新前的值”为空，则相当于做删除操作
- 删除操作，“更新后的值”为空，则相当于做插入操作
- 修改操作，则相当于用修改前值代替修改后值
继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理
如此处理下去，直到读到此事务的开始标记，事务故障恢复就完成了。

系统故障的恢复

恢复策略：

撤销（UNDO）故障发生时未完成的事务
重做（REDO）已完成的事务

系统故障的恢复由系统在重新启动时自动完成，对用户透明。

恢复步骤：

正向扫描日志文件（即从头向后扫描日志文件），找出故障发生前已提交的事务(特征：既有BEGIN TRANSACTION记录，也有COMMIT记录)，将其事务标识记入重做队列（REDO-LIST）。同时找出故障发生时尚未完成的事务(特征：只有BEGIN TRANSACTION记录，无相应的COMMIT记录)，将其事务标识记入撤销队列（UNDO-LIST）。
对撤销队列中的各个事务进行撤销(UNDO)处理。
- 方法：反向扫描日志文件，对每个撤销事务的更新操作执行逆操作，即将日志文件中“更新前的值”写入数据库
对重做队列中的各个事务进行重做处理。
- 方法：正向扫描日志文件，对每个重做事务重新执行日志文件登记的操作，即将日志文件中“更新后的值”写入数据库

介质故障的恢复

恢复策略：

重装数据库，然后重做已完成的事务。

介质故障的恢复需要DBA介入——DBA重装最近转储的数据库副本和有关的日志文件副本，然后执行命令，具体恢复由DBMA完成。

恢复步骤：

装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态。
- 对静态转储的数据库副本，装入后数据库即处于一致性状态
- 对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态
装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。
- 即首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列；然后正向扫描日志文件，对重做队列中的所有事务进行重做处理，即将日志记录中“更新后的值”写入数据库。

具有检查点的恢复技术

日志技术搜索过程中存在的问题：

搜索整个日志将耗费大量的实践
重做处理：重做执行，浪费了大量时间。

解决方案：具有检查点的恢复技术。

在日志记录中增加检查点记录
增加重新开始文件
回复子系统在登录日志文件期间动态地维护日志

检查点记录的内容：

建立检查点时刻所有正在执行的事务清单
这些事务最近一个日志记录的地址

重新开始文件

重新开始文件用来记录各个检查点记录在日志文件中的地址。

动态维护日志文件的方法：

周期性地执行：建立检查点、保持数据库状态
具体步骤：
1. 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上
2. 在日志文件中写入一个检查点记录
3. 将当前数据缓冲区的所有数据记录写入磁盘的数据库中
4. 把检查点记录在日志文件中的地址写入一个重新开始文件

恢复子系统建立检查点的一般方法：

定期：按预定的一个时间间隔建立。

不定期：按某种规则建立。

恢复策略：

当事务T在一个检查点之前提交，T对数据库所做的修改一定都已写入数据库，写入时间是在这个检查点建立之前或在这个检查点建立之时，
这样，在进行恢复处理时，没有必要对事务T执行重做操作

恢复步骤：

从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录
由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST
- UNDO-LIST：需要执行UNDO操作的事务集合
- REDO-LIST：需要执行REDO操作的事务集合
从检查点开始正向扫描日志文件：

①如有新开始的事务Ti，把Ti暂时放入UNDO-LIST队列；

②如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列

③继续以上过程，直到日志文件结束。
对UNDO-LIST中的每个事务执行UNDO操作，对REDO-LIST中的每个事务执行REDO操作。

数据库镜像

数据库镜像(Mirror)是解决介质故障、提高数据库可用性的一种常用方法。

即根据DBA的要求，自动把整个数据库或其中的关键数据复制到另一个磁盘上。每当主数据库更新时，DBMS自动把更新后的数据复制过去，由DBMS自动保证镜像数据与主数据库的一致性。

由于数据库镜像是通过复制数据实现，频繁地复制数据自然会降低系统运行效率，因此在实际应用中只对关键数据和日志文件进行镜像，而不是整个数据库。