数据库恢复技术知识点合集（复习总结）

施霁

已于 2024-06-12 13:36:17 修改

阅读量1k

点赞数 29

分类专栏：数据库原理文章标签：数据库

于 2024-06-12 13:35:46 首次发布

本文链接：https://blog.csdn.net/m0_73962294/article/details/139560937

版权

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

2 篇文章 0 订阅

订阅专栏

一、事务的基本概念

事务：用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位（恢复和并发控制的基本单位）
事务与程序：在关系数据库中，一个事务可以是一条或多条sql语句，也可以包含一个或多个程序；一个程序通常包含多个事务
事务定义
1. 显式定义（start transaction 或者begin---commit或者rollback）
2. 隐式定义DBMS按缺省规定自动划分事务
事务结束
1. Commit
  1. 事务正常结束
  2. 提交事务的所有操作（读+更新）
  3. 事务中所有对数据库的更新写回到磁盘上的物理数据库中
2. Rollback
  1. 事务异常终止
  2. 事务运行的过程中发生了故障，不能继续执行
  3. 系统将事务中对数据库的所有已完成的更新操作全部撤销
  4. 事务滚回到开始时的状态

二、事务的ACID特性

1. 原子性

事务是数据库的逻辑工作单位
事务中包括的诸操作要么都做，要么都不做（简单来说就是事务是一个整体）

2. 一致性

事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态

一致性状态（数据正确的状态）：在事务间没有干扰的情况下，数据库中只包含成功事务提交的结果；
不一致状态：数据库中包含未完成事务的结果。

注：一致性和原子性密切相关，为什么？看下图

原子性就说明了要么都做要么都不做，但是你只做一个操作，那这个事务就没有完成，就可能保证不了事务的一致性了。

3. 隔离性

一个事务的执行不能被其他事务干扰

一个事务内部的操作及使用的数据对其他并发事务是隔离的
并发执行的各个事务之间不能互相干扰

4. 持续性

一个事务一旦提交，它对数据库中数据的改变就应该是永久性的
即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作

5. 事务的特性——（重要）

保证事务ACID特性是事务处理的任务
破坏事务ACID特性的因素
- 多个事务并行运行时，不同事务的操作交叉执行；
- 事务在运行过程中被强行停止。

三、数据库恢复概述

系统故障：计算机软、硬件故障
人为故障：操作员的失误、恶意的破坏等

故障的影响：事务的非正常中断，影响数据库的正确性；破坏数据库，导致全部或部分数据丢失。

DBMS提供恢复子系统
数据库恢复：把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）
恢复子系统是数据库管理系统的一个重要组成部分
恢复技术是衡量数据库管理系统优劣的重要指标

四、故障的种类

1. 事务内部的故障

某个事务在运行过程中由于种种原因未运行至正常终止点就夭折了（非正常终止）

可预期的，可以通过事务程序本身发现，及时回滚保证数据库的一致性；
非预期的，不能由事务程序处理的，比如求阶乘，导致数据外溢。

事务内部更多的故障是非预期的，是不能由应用程序处理的，比如：

输入数据有误
运算溢出
并发事务发生死锁而被选中撤销该事务
违反了某些完整性限制等

事务故障意味着事务没有达到预期的终点（COMMIT或者显式的ROLLBACK），数据库可能处于不正确的状态！！！

事务故障的恢复：事务撤销（UNDO）

强行回滚该事务
撤销该事务已经做出的任何对数据库的修改，使得该事务像根本没有启动

2. 系统故障——软故障

是指造成系统停止运转的任何事件，使得系统重新启动。影响正在运行的所有事务，但不破坏数据库；
所有正在运行的事务都非正常终止；
内存中数据库缓冲区的信息全部丢失；
部分尚未完成的事务的结果可能已送入物理数据库，从而造成数据库可能处于不正确的状态；

1. 系统故障的原因

特定类型的硬件错误（如CPU故障）
操作系统故障
DBMS代码错误
系统断电
导致系统崩溃的计算机病毒

2. 系统故障的恢复

发生系统故障时，事务未提交，直接强行撤销（UNDO）所有没有完成的事务；
发生系统故障时，事务已提交，但是缓冲区的信息尚未完全写回磁盘，直接重做（REDO）所有已提交的事务。

3. 介质故障——硬故障

指外存故障，破坏性最大

1. 介质故障的原因

磁盘损坏
磁头碰撞
操作系统的某种潜在错误
瞬时强磁场干扰
破坏硬盘数据的计算机病毒

2. 介质故障的恢复

需要借助存储在其他地方的数据备份来恢复数据库；
装入数据库发生介质故障前某个时刻的数据副本；
重做自此时始的所有成功事务，将这些事务已提交的结果重新记入数据库；

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

数据库本身被破坏：介质故障，计算机病毒
数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的：事务内部故障，系统故障，计算机病毒

五、恢复的实现技术

恢复操作的基本原理：（冗余）利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据；
恢复机制涉及的关键问题
1. 如何利用冗余数据进行恢复：数据转储+登记日志文件
2. 如何建立冗余数据
数据转储

DBA将整个数据库复制到其他存储介质上保存起来的过程，备用的数据称为后备副本或后援副本。

如何使用：

数据库遭到破坏后可以将后备副本重新装入；
重装后备副本只能将数据库恢复到转储时的状态；（原始状态，回到解放前）
要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务；

1. 静态转储与动态转储

1. 静态转储

实现简单，但降低了数据库的可用性

1. 得到的一定是一个数据一致性的副本

2. 转储期间不允许对数据库的任何存取、修改活动

3. 转储开始时数据库处于一致性状态

4. 在系统中无运行事务时进行的转储操作

转储必须等待正在运行的用户事务结束，新的事物必须等转储结束！

2. 动态转储

1. 转储操作与用户事务并发进行

2. 转储期间允许对数据库进行存取或修改（这里就能反应副本中的数据可能不正确）

优点：1. 不用等待正在运行的用户事务结束 2. 不会影响新事务的运行

缺点：不能保证副本中的数据正确有效

注：利用动态转储得到的副本进行故障恢复，需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件！！！

后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态。

动态转储+日志文件

2. 海量转储与增量转储

1. 海量转储

每次转储全部数据库；

2. 增量转储

只转储上次转储后更新过的数据；

3. 登记日志文件

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

1. 日志文件的格式和内容

1. 以记录为单位的日志文件：记录各个事务的开始标记，结束标记以及所有更新操作；

2. 以数据块为单位的日志文件：记录事务的标识和被更新的数块；

2. 日志文件的作用

1. 事务故障恢复和系统故障恢复，必须用日志文件；

2. 静态转储后的后备副本进行介质故障恢复，也可用日志文件；

3. 动态转储后的后备副本进行介质故障恢复，必须用日志文件；

3. 登记日志文件

基本原则：

1. 登记的次序严格按并行事务执行的时间次序

2. 必须先写日志文件，后写数据库（就是说你要做操作了就先写入日志文件中，写完之后在对数据修改到数据库中）
先写日志文件的原因：

六、恢复策略

1. 事务故障的恢复

由恢复子系统利用日志文件撤销（UNDO）此事务已对数据库进行的修改；（由系统自动完成，对用户透明，不需要用户干预）

解决方式：

1. 反向扫描日志文件（从最后开始向前扫描）；

2. 对事务的更新操作执行逆操作，直到读到此事务的开始标记；

2. 系统故障的恢复

在系统重启时自动完成，不需要用户干预

解决方式：

正向扫描日志文件（从头开始扫描日志文件），划分一下两类：

1. REDO队列，故障发生前已经提交的事务T1，T3，T8……；

2. UNDO队列，故障发生前尚未完成的事务T2，T4，T5……；

这里有点不一样了！！！

1. 对UNDO队列的事务进行UNDO处理：反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作；

2. 对REDO队列的事务进行REDO处理：正向扫描日志文件，对每个REDO事务重新执行登记的操作；

3. 介质故障恢复

需要DBA介入，具体的恢复操作仍由DBMS完成

解决方式：利用数据库后备副本和日志文件进行恢复

DBA的工作：

重装最近转储的数据库副本和有关的各日志文件副本；
执行系统提供的恢复命令；

恢复步骤：

装入最新的后备数据库副本(离故障发生时刻最近的转储副本) ，使数据库恢复到最近一次转储时的一致性状态；

注：

对于静态转储的数据库副本，装入后数据库即处于一致性状态；
装入有关的日志文件副本(转储结束时刻的日志文件副本) ，重做已完成的事务。
对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用与恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。

总结：