模块三：事务、故障恢复与备份方案

这一部分对应开卷考核的模块三，满分10分。教材的数据库恢复技术章节围绕事务、故障种类、恢复技术、恢复策略、检查点和数据库镜像展开。考核要求明确要求分析三类故障，并制定备份、恢复和日志方案。

本模块的答题关键不是写一句“定期备份”，而是说明：

可能发生什么故障；
哪些数据会受到影响；
用什么备份与日志恢复；
发生故障后按什么步骤操作。

---

1. 事务的基本概念

1.1 什么是事务

事务是数据库中的一个逻辑工作单位，由一组操作组成。这组操作要么全部完成，要么全部不生效。

例如订单支付流程可能包括：

创建支付记录；
修改订单状态为已支付；
减少商品库存；
记录业务日志。

如果扣减库存成功，但订单状态更新失败，数据库就会出现不一致。因此这些相关操作应放入同一事务中。

1.2 SQL示例

以下表示一个简化事务：

START TRANSACTION;

UPDATE Product
SET StockQuantity = StockQuantity - 1
WHERE ProductID = 101
  AND StockQuantity >= 1;

UPDATE Orders
SET OrderStatus = '已支付'
WHERE OrderID = 1001;

COMMIT;

如果执行中发现库存不足或语句出错，应撤销本事务：

ROLLBACK;

不同数据库的事务开启命令可能略有差异，报告中应按自己实际使用的 MySQL 或 openGauss 环境调试。

---

2. 事务的ACID特性

特性	英文	含义	订单场景示例
原子性	Atomicity	事务中的操作要么全做，要么全不做	扣库存和改订单状态不能只完成一半
一致性	Consistency	事务执行前后数据库满足约束	库存不能变为负数，外键引用有效
隔离性	Isolation	并发事务互不造成错误干扰	两名用户不能同时成功购买最后一件库存
持久性	Durability	已提交结果在故障后仍应保存	支付成功并提交后，系统重启不能丢失记录

在模块三中，恢复技术尤其服务于：

原子性：失败事务要撤销。
持久性：已提交事务在故障后要重做。

---

3. 三类故障分析

考试要求中点名了三类故障。答题时建议结合当天业务各举一个具体例子。

3.1 事务故障

事务故障是某一个事务无法正常完成，需要被撤销，而数据库系统整体仍然可以运行。

可能原因：

输入数据违反约束，例如库存不足仍尝试扣减；
程序逻辑错误或SQL语句出错；
事务被用户主动取消；
并发处理中发生死锁，某个事务被系统回滚。

业务例子：

在创建订单明细时，商品编号不存在，违反外键约束，导致本次订单事务失败。

恢复重点：

撤销该事务已经执行但尚未成功完成的修改，即UNDO。

3.2 系统故障

系统故障会使正在运行的事务全部中断，但磁盘上的数据库文件通常没有物理损坏。

可能原因：

服务器断电；
操作系统崩溃；
数据库服务异常退出；
硬件临时故障导致重启。

业务例子：

订单处理高峰期服务器突然断电，部分事务已经提交，部分事务仍处于执行过程中。

恢复重点：

根据日志撤销未提交事务的修改；
根据日志重做已经提交但尚未稳定写入数据文件的修改。

即：

UNDO未提交事务，REDO已提交事务。

3.3 介质故障

介质故障是数据库存储介质发生损坏，导致数据文件无法正常读取，是影响最严重的一类故障。

可能原因：

磁盘损坏；
数据库文件被误删除或覆盖；
存储设备故障；
严重灾害造成服务器和数据文件丢失。

业务例子：

保存订单与支付数据的磁盘损坏，主数据文件无法打开。

恢复重点：

先从备份恢复数据库，再利用备份之后产生的日志重做已提交事务，使数据恢复到尽可能新的正确状态。

---

4. 日志文件与UNDO、REDO

4.1 日志记录什么

日志文件用于记录数据库更新活动，通常需要包含：

事务开始；
事务对哪些数据进行了修改；
修改前的旧值；
修改后的新值；
事务提交或回滚标志。

示意：

<T1, START>
<T1, Product.StockQuantity, 20, 19>
<T1, Orders.OrderStatus, 待支付, 已支付>
<T1, COMMIT>

4.2 UNDO

UNDO用于撤销未成功提交的事务，通常需要日志中的旧值。

例如系统故障时发现：

事务T2有START记录，有修改记录，但没有COMMIT记录。

则应该用旧值撤销它已执行的修改。

4.3 REDO

REDO用于重做已经提交但可能尚未写入数据库文件的修改，通常使用日志中的新值。

例如：

事务T1已经出现COMMIT记录，但系统随后立即断电。

恢复时应重做T1，保证已提交结果不会丢失。

4.4 先写日志原则

理解恢复时应记住一个核心思想：

在数据修改真正写入数据库文件之前，相关日志记录应先可靠写入稳定存储。

这样即使随后发生故障，系统仍然知道应该撤销什么或重做什么。

---

5. 检查点的作用

如果数据库长期运行，日志会越来越长。系统重启后若从最早日志逐条恢复，效率很低。

检查点用于记录某个恢复起点，使恢复时不必处理所有历史日志。

检查点的价值：

缩短故障后的恢复时间；
明确故障发生前后需要检查的事务范围；
减少对过早、已经稳定完成事务的重复处理。

报告中可以写：

系统通过周期性建立检查点，将已稳定写入的数据状态作为恢复参考。发生系统故障时，优先从最近检查点及其后的日志开始分析未提交与已提交事务，从而提高恢复效率。

---

6. 日常备份策略设计

一套可信的备份策略要同时考虑：

备份频率；
备份类型；
备份存放位置；
日志保存周期；
恢复演练。

6.1 备份类型

备份类型	含义	优点	不足
全量备份	备份整个数据库	恢复基础清晰	占空间大、耗时较长
增量备份	备份自上次备份以来变化的数据	速度快、空间小	恢复时需要依次组合多个备份
日志备份/归档	保存事务日志	可恢复到较新时间点	需要与基础备份配合

6.2 可用于报告的备份方案

下面是一套适合一般业务系统的方案，考试时可替换成当天业务名称：

时间或条件	备份措施	目的
每周末	执行一次全量备份	提供完整恢复基线
每天业务结束后	执行一次增量备份	保存当天新增或修改的数据
业务运行期间	持续保存并归档事务日志	支持故障后的UNDO、REDO和时间点恢复
每月	在测试环境进行恢复演练	验证备份可用而非只“存在”
备份保存	本地备份与异地/独立存储各保存一份	防止介质故障同时破坏数据与备份

---

7. 不同故障的恢复流程

7.1 事务故障恢复流程

1. 检测事务出错或违反约束。
2. 停止该事务继续修改数据。
3. 根据日志中的旧值撤销该事务已做的修改。
4. 执行ROLLBACK，并记录失败原因。
5. 修正输入或程序逻辑后重新发起事务。

答题示例：

若用户下单时库存不足导致事务失败，系统回滚本次订单创建及库存修改，保证不会出现订单已生成而库存扣减不一致的问题。

7.2 系统故障恢复流程

1. 数据库服务重启并进入恢复阶段。
2. 从最近检查点开始读取事务日志。
3. 找出故障前已提交的事务和未提交的事务。
4. 对未提交事务执行UNDO。
5. 对已提交但可能未写入数据文件的事务执行REDO。
6. 完成一致性检查后恢复业务服务。

7.3 介质故障恢复流程

1. 停止继续写入受损数据文件，确认故障范围。
2. 修复或更换存储介质。
3. 恢复最近一次可用的全量备份。
4. 按顺序应用之后的增量备份。
5. 应用归档日志，重做备份后已提交的事务。
6. 校验关键业务表、约束和统计结果。
7. 恢复应用访问，并保留故障与恢复记录。

---

8. 与业务结合的报告示例结构

考试报告可以用下面结构完成模块三。

8.1 系统关键数据说明

本系统的关键数据包括______基本信息、______业务记录和______结果记录。其中，业务记录与结果记录直接影响用户权益，因此需要通过事务和备份机制保证一致性与可恢复性。

8.2 故障分析表

故障类型	本系统可能场景	影响	恢复方法
事务故障	插入明细时违反外键或数量约束	单次业务处理未完成	回滚事务，UNDO未提交修改
系统故障	服务处理业务时突然断电	内存中事务中断	日志分析，UNDO未提交，REDO已提交
介质故障	数据文件所在磁盘损坏	数据文件不可用	从备份恢复，再应用增量与日志

8.3 备份和日志方案段落

本系统采用“周期性全量备份 + 每日增量备份 + 持续日志归档”的策略。每周进行全量备份，每日业务结束后进行增量备份，数据库运行过程中保留事务日志并设置检查点。事务故障时依据日志撤销失败事务；系统故障时从最近检查点分析日志，对未提交事务UNDO、对已提交事务REDO；介质故障时先恢复全量及增量备份，再利用日志恢复到故障前的最新一致状态。

---

9. 常见失分点

失分写法	问题	应如何完善
“数据库可能崩溃，要及时备份”	太笼统，没有对应题目要求	分别写事务、系统、介质故障
只有备份，没有日志	不能解释近期已提交事务如何恢复	加上UNDO、REDO与日志归档
介质故障只写重启	文件已损坏，重启无法解决	从备份恢复并应用日志
方案与业务完全无关	缺少设计感	写出本系统关键数据和具体影响
只写概念，不写流程	不便于评分	使用故障分析表和步骤列表

---

10. 本模块快速背诵版

事务是数据库中的逻辑工作单位，具有原子性、一致性、隔离性和持久性。事务故障只影响某个事务，应撤销该事务的修改；系统故障使运行中的事务中断，但磁盘数据通常未损坏，恢复时应UNDO未提交事务并REDO已提交事务；介质故障造成数据库文件损坏，应先恢复备份，再利用日志恢复后续已提交事务。

日志记录事务的更新操作、旧值、新值及提交状态，是UNDO与REDO的基础。检查点能够缩短系统故障后的日志扫描和恢复时间。备份策略应包括周期性全量备份、日常增量备份、持续日志归档和定期恢复演练。