mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
620 字
2 分钟
软考中级软件设计师 · 数据库知识点
2026-04-27

软考中级软件设计师 · 数据库知识点#

整理时间:2026-04-27 来源:错题本 用途:考前冲刺快速回忆


📌 数据库事务#

✅ 日志文件与故障恢复#


一、日志文件记录内容#

日志文件记录事务对数据库的所有操作:

操作类型日志内容
事务开始BEGIN TRANSACTION
插入操作INSERT + 数据内容
删除操作DELETE + 被删除数据旧值
修改操作UPDATE + 旧值和新值
事务结束COMMIT(提交)或 ROLLBACK(回滚)

注意: 日志文件记录的是数据修改前后的值,而不是结果本身。


二、三种故障类型及恢复策略#

故障类型恢复策略具体做法
事务故障UNDO(撤销)反向扫描日志,撤销该事务对数据库的所有修改
系统故障UNDO + REDO撤销未完成事务,重做已提交但未写入数据库的事务
介质故障备份 + 日志先恢复最近的数据库备份,再用日志重做所有已提交事务

详细说明:

① 事务故障(UN/DO)

发生场景:某事务因逻辑错误或输入错误被中止
恢复方法:
- 反向扫描日志,找到该事务的所有操作
- 逐一执行逆操作(UNDO)
- 标记事务为回滚完成
例子:T1执行了INSERT/UPDATE,还没COMMIT就崩溃了 → UNDO

② 系统故障(UNDO+REDO)

发生场景:硬件故障、软件Bug、掉电等
恢复方法(两阶段):
- 阶段一:撤销(UNDO)所有未完成事务(未COMMIT的)
- 阶段二:重做(REDO)所有已提交但可能未写入数据库的事务

③ 介质故障(恢复备份+日志)

发生场景:磁盘损坏、文件系统崩溃
恢复方法:
1. 装入最近的数据库备份
2. 从备份后第一个检查点(CHECKPOINT)开始
3. 扫描日志,重做(REDO)所有已提交的事务

三、核心原则#

1. 先写日志原则(Write-Ahead Logging,WAL)

规定:任何对数据库的修改,必须先写入日志文件,再修改数据库本身。
原因:日志是恢复的根据,如果先改数据库再写日志,一旦崩溃就无法恢复。
口诀:先写日志后操作,日志没写不落盘。

2. 检查点(Checkpoint)

定义:系统定期将缓冲区中的所有修改写回磁盘,并在日志中写入检查点记录。
作用:
- 将已完成的事务结果持久化
- 减少恢复时需要扫描的日志范围
- 提高恢复效率
恢复时:从最近的检查点开始扫描,不必从头扫描全部日志

3. 恢复子系统工作流程

故障发生
查找最近的检查点(Checkpoint)
从检查点开始扫描日志
识别未完成事务 → 执行 UNDO(撤销)
识别已提交但未写入的事务 → 执行 REDO(重做)
恢复完成

四、UNDO vs REDO 对比#

对比项UNDO(撤销)REDO(重做)
方向逆向(从后往前)正向(从前往后)
目的消除已做操作的影响补做未落盘的操作
依据数据的旧值(Before Image)数据的新值(After Image)
适用事务故障、系统故障系统故障、介质故障
日志要求必须有旧值记录必须有新值记录

五、记忆口诀#

日志先写后操作(WAL)—— 先记日志再改数据
事务故障只撤销(UNDO)—— 未提交的事务全部回滚
系统故障撤加重(UNDO+REDO)—— 未提交的撤销,已提交未落盘的重做
介质故障备份+日志—— 先恢复备份,再用日志重做
检查点定期打,缩短恢复扫描范围

📌 相关知识点速查#

事务的ACID特性#

特性含义保证机制
A 原子性事务要么全做,要么全不做UNDO日志
C 一致性事务执行前后数据库状态一致完整性约束
I 隔离性并发事务互不干扰并发控制(锁/MVCC)
D 持久性提交后修改永久保存REDO日志

联系: 持久性靠 REDO 日志保证;原子性靠 UNDO 日志保证


整理自软考中级软件设计师错题本 · 持续更新中

分享

如果这篇文章对你有帮助,欢迎分享给更多人!

软考中级软件设计师 · 数据库知识点
https://www.rumin.top/posts/数据库知识点_软考软件设计师/
作者
Rumin
发布于
2026-04-27
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

目录

封面
Sample Song
Sample Artist
封面
Sample Song
Sample Artist
0:00 / 0:00