软考中级数据库系统工程师学习专篇（67、数据库恢复）
67、数据库恢复
数据库故障恢复中基于检查点的事务分类与处理策略
在数据库系统发生故障后的恢复过程中，检查点（Checkpoint） 技术是关键机制，它能有效缩小恢复范围，减少需要扫描的日志量，从而加速恢复进程
。其核心逻辑是：系统只需从最后一个检查点开始恢复，而不必处理整个日志文件。具体解题思路如下：
- 1.
定位最近检查点：首先，在日志文件中找到最近的一个检查点记录。检查点是数据库系统定期写入的一个特殊记录，它标志着在该时间点之前，所有已提交事务对数据库的修改都已经从内存缓冲区刷新到了物理磁盘上，数据库处于一个已知的一致状态
。 - 2.
识别检查点时刻的活动事务：查看该检查点记录中包含的信息（通常包含一个活动事务列表），或向前扫描日志，找出所有在检查点记录之前有
START标志但尚未有COMMIT或ROLLBACK结束标志的事务。这些事务在检查点时刻是活动事务（Active Transactions）。 - 3.
对事务进行分类处理：根据事务的完成时间点相对于检查点的位置，将其分为三类，并采取不同的恢复策略：
事务类别 | 特征 | 恢复动作 | 原因 |
|---|---|---|---|
① 检查点前已提交的事务 | 在检查点记录之前就已经有 | 无需任何操作 | 这类事务的修改在检查点时已被保证写入磁盘，数据已持久化，因此无需恢复操作。 |
② 检查点后提交的事务 | 在检查点记录之后才出现 | REDO (重做) | 这些事务的提交发生在检查点之后，其数据修改可能仍在内存缓冲区而未写入磁盘（系统故障导致内存丢失）。因此需要根据日志重做所有操作，确保修改不丢失。 |
③ 始终未提交的事务 | 在检查点之前开始，但在检查点之后、故障点之前始终没有 | UNDO (撤销) | 这些活动事务从未真正完成，为防止它们对数据库的部分修改导致数据不一致，必须根据日志撤销其所有操作，回滚到事务开始前的状态。 |
总而言之，检查点机制通过确立一个可靠的恢复起点，将复杂的事务恢复问题转化为对三类事务的针对性操作：忽略已完成的、重做已提交但未落盘的、撤销从未完成的。这种分类处理方法极大地提高了数据库故障恢复的效率和可靠性