数据库系统概论第十章-数据库恢复技术

JAY.LIN 收录于数据库

2025-03-11 约 3393 字预计阅读 7 分钟

https://bing.ee123.net/img/rand?artid=146148056

【数据库系统概论】第十章数据库恢复技术

10.1 事务的基本概念

10.1.1 事务

事务(Transaction)是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。
事务是恢复和并发控制的基本单位
事务和程序是两个概念
在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序
一个程序通常包含多个事务

10.1.2 事务的ACID特性

原子性 （Atomicity）：事务中包括的诸操作要么都做，要么都不做
一致性 （Consistency）：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态
隔离性 （Isolation）：一个事务的执行不能被其他事务干扰
持续性 （Durability ）：一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。

10.2 数据库恢复概述

数据库的恢复：数据库管理系统必须具有把数据库 从错误状态恢复到某一已知的正确状态 (亦称为一致状态或完整状态)的功能，这就是数据库的恢复管理系统对故障的对策

10.3 故障的种类

（1）事务内部的故障

事务内部的故障类型，分为两类： 可以通过事务程序本身发现的故障 和 非预期的、不能由事务程序处理的故障 。

可以通过事务程序本身发现的故障 ：这类故障是事务在执行过程中遇到的 预期错误 ，通常可以通过事务程序中的逻辑检测和处理。

转账事务：从账户 A 转账 100 元到账户 B。
事务程序可以检查账户 A 的余额是否足够。
如果余额不足，事务程序可以主动回滚事务，并返回错误信息。

非预期的、不能由事务程序处理的故障 ：这类故障是事务在执行过程中遇到的 意外错误 ，通常无法通过事务程序的逻辑检测和处理， 需要数据库系统的恢复机制来解决 。

系统崩溃：在事务执行过程中，数据库系统突然崩溃。
事务程序无法处理这种情况，需要数据库系统在重启后通过日志恢复机制来回滚未完成的事务。

硬件故障：例如磁盘损坏导致数据丢失。
事务程序无法处理这种情况，需要数据库系统通过备份和日志恢复机制来恢复数据。

死锁：多个事务相互等待资源，导致事务无法继续执行。
事务程序无法主动检测死锁，需要数据库系统的死锁检测机制来解除死锁。

（2）系统故障

系统故障：称为软故障，是指 造成系统停止运转的任何事件 ，使得系统要重新启动。
系统故障的常见原因
特定类型的硬件错误（如CPU故障）
操作系统故障
数据库管理系统代码错误
系统断电

（3）介质故障

介质故障称为硬故障，指外存故障
介质故障的常见原因
磁盘损坏
磁头碰撞
瞬时强磁场干扰

（4）计算机病毒

计算机病毒：一种人为的故障或破坏，是一些恶作剧者研制的一种计算机程序
可以繁殖和传播 ，造成对计算机系统包括数据库的危害

10.4 恢复的实现技术

恢复操作的基本原理：冗余
利用存储在系统别处的冗余数据来重建数据库中已被破坏或不正确的那部分数据
冗余是指在系统中存储额外的数据，以便在数据丢失或损坏时能够恢复原始数据。
如何建立冗余数据?
- 数据转储（backup）
- 登记日志文件（logging）
如何利用这些冗余数据实施数据库恢复?

10.4.1 数据转储

10.4.1.1 数据转储的概念

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

系统在Ta时刻停止运行事务，进行数据库转储
在Tb时刻转储完毕，得到Tb时刻的数据库一致性副本
系统运行到Tf时刻发生故障
为恢复数据库，首先由数据库管理员重装数据库后备副本，将数据库恢复至Tb时刻的状态
重新运行自Tb～Tf时刻的所有更新事务，把数据库恢复到故障发生前的一致状态

10.4.1.2 转储方法

（1）静态转储与动态转储

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

动态转储
- 转储操作与用户事务并发进行
- 转储期间允许对数据库进行存取或修改
- 优点：不用等待正在运行的用户事务结束，不会影响新事务的运行
- 缺点：不能保证副本中的数据正确有效
```
例在转储期间的某时刻Tc，系统把数据A=100转储到磁带上，而在下一时刻Td，某一事务将A改为200。
后备副本上的A过时了
```
动态转储的故障恢复过程：
1. 动态转储 ：在数据库运行期间进行转储，得到一个 后备副本 （即某一时刻的数据库快照）。
2. 记录日志 ：在转储期间，所有事务对数据库的修改操作都会被记录到 日志文件 中。日志文件包含了事务的开始、提交、回滚以及具体的修改操作（如更新、插入、删除）。
3. 故障恢复 ：
  - 当数据库发生故障时，可以使用 后备副本 和 日志文件 来恢复数据库。
  - 首先，将数据库恢复到后备副本的状态（即转储开始时的状态）。
  - 然后，根据日志文件中的记录，重新执行（Redo）转储之后所有已提交的事务，撤销（Undo）未提交的事务，最终将数据库恢复到故障发生前的某一正确状态。

假设你是一个图书管理员，负责管理图书馆的书籍。这次你决定在图书馆开放期间记录书籍的状态（动态转储），而不是闭馆后记录（静态转储）。

1. 动态转储：
   - 你开始记录书籍的状态（后备副本），但图书馆仍然开放，读者可以继续借书或还书。
   - 在记录期间，你用一个本子（日志文件）记下每一位读者的借书和还书操作。

2. 故障发生：
   - 突然，图书馆的电脑系统崩溃了，导致书籍的最新状态丢失。

3. 故障恢复：
   - 你首先根据之前记录的书籍状态（后备副本）恢复图书馆的基本状态。
   - 然后，你翻开本子（日志文件），查看在记录期间所有读者的借书和还书操作。
   - 对于已经完成的借书和还书操作（已提交的事务），你重新执行这些操作，更新书籍的状态。
   - 对于未完成的操作（未提交的事务），你忽略或撤销这些操作。
   - 最终，图书馆的书籍状态被恢复到系统崩溃前的正确状态。

（2）海量转储与增量转储

海量转储: 每次转储全部数据库
增量转储: 只转储上次转储后更新过的数据

10.4.2 登记日志文件

10.4.2.1 日志文件的格式和内容

日志文件(log file)是用来记录事务对数据库的更新操作的文件
日志文件的格式
- 以记录为单位的日志文件
- 以数据块为单位的日志文件

10.4.2.2 日志文件的作用

事务故障恢复和系统故障恢复必须用日志文件。
在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库。

10.4.2.3 登记日志文件

为保证数据库是可恢复的，登记日志文件时必须遵循两条原则
1. 登记的次序严格按并发事务执行的时间次序
2. 必须先写日志文件，后写数据库

10.5 恢复策略

10.5.1 事务故障的恢复

事务故障：事务在运行至正常终止点前被终止
事务故障的恢复 ：事务故障的恢复是通过 日志文件 和 撤销（UNDO）操作 来实现的。
事务故障的恢复步骤
- 反向扫描文件日志 ，对这些操作执行 逆向操作 （即撤销），将数据库恢复到事务执行前的状态。
  - 如果事务修改了某条记录，恢复子系统会将记录的值改回原来的值。
  - 如果事务插入了一条新记录，恢复子系统会删除这条记录。
  - 如果事务删除了某条记录，恢复子系统会重新插入这条记录。

10.5.2 系统故障的恢复

系统故障造成数据库不一致状态的原因
1. 未完成事务对数据库的更新可能已写入数据库
2. 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库
系统故障的恢复
1. Undo 故障发生时未完成的事务
2. Redo 已完成的事务
系统故障的恢复步骤
1. 正向扫描日志文件
  重做(REDO) 队列: 在故障发生前已经提交的事务
  撤销 (UNDO)队列:故障发生时尚未完成的事务
2. 对撤销(UNDO)队列事务进行撤销(UNDO)处理
  反向扫描日志文件，对每个撤销事务的更新操作执行逆操作
3. 对重做(REDO)队列事务进行重做(REDO)处理
  正向扫描日志文件，对每个重做事务重新执行登记的操作

10.5.3 介质故障的恢复

介质故障的恢复
1. 重装数据库
2. 重做已完成的事务

10.6 具有检查点的恢复技术

10.6.1 检查点技术

具有检查点（checkpoint）的恢复技术：

① 在日志文件中增加检查点记录（checkpoint）

②增加重新开始文件：记录各个检查点记录在日志文件中的地址

③恢复子系统在登录日志文件期间动态地维护日志：建立检查点，保存数据库状态。

10.6.2 利用检查点的恢复策略

T3和T5在故障发生时还未完成，所以予以撤销
T2和T4在检查点之后才提交，它们对数据库所做的修改在故障发生时可能还在缓冲区中，尚未写入数据库，所以要重做
T1在检查点之前已提交，所以不必执行重做操作

10.7 数据库镜像

数据库管理系统自动把整个数据库或其中的 关键数据+日志文件 复制到另一个磁盘上

出现介质故障时
- 可由镜像磁盘继续提供使用
- 同时数据库管理系统自动利用镜像磁盘数据进行数据库的恢复
- 不需要关闭系统和重装数据库副本