数据库崩溃恢复：ARIES算法详解

### 数据库崩溃恢复：ARIES算法详解 #### 1. 数据库恢复管理器的职责 数据库管理系统（DBMS）的恢复管理器负责确保事务的两个重要属性：原子性和持久性。它通过撤销未提交事务的操作来保证原子性，通过确保已提交事务的所有操作在系统崩溃（如总线错误导致的核心转储）和介质故障（如磁盘损坏）后仍然存在来保证持久性。 #### 2. ARIES恢复算法简介 ARIES是一种为“偷取（steal）、不强制（no - force）”方法设计的恢复算法。系统崩溃后调用恢复管理器时，重启过程分为三个阶段： 1. **分析（Analysis）**：识别缓冲池中的脏页（即尚未写入磁盘的更改）和崩溃时的活跃事务。 2. **重做（Redo）**：从日志中的适当点开始重复所有操作，将数据库状态恢复到崩溃时的状态。 3. **撤销（Undo）**：撤销未提交事务的操作，使数据库仅反映已提交事务的操作。 ARIES恢复算法基于以下三个主要原则： - **预写日志（Write - Ahead Logging）**：对数据库对象的任何更改首先记录在日志中；日志记录必须在数据库对象的更改写入磁盘之前写入稳定存储。 - **重做时重复历史（Repeating History During Redo）**：崩溃重启后，ARIES追溯崩溃前DBMS的所有操作，使系统恢复到崩溃时的精确状态，然后撤销崩溃时仍活跃的事务的操作。 - **撤销时记录更改（Logging Changes During Undo）**：撤销事务时对数据库所做的更改会被记录，以确保在重复重启（由故障引起）时不会重复该操作。 以下是一个简单的执行历史示例： | LSN | 操作 | | --- | --- | | 10 | update: T1 writes P5 | | 20 | update: T2 writes P3 | | 30 | T2 commit | | 40 | CRASH, RESTART | | 50 | update: T3 writes P3 | | 60 | update: T3 writes P1 | | 70 | T2 end | 系统重启时，分析阶段识别出T1和T3为崩溃时的活跃事务，需要撤销；T2为已提交事务，其所有操作需写入磁盘；P1、P3和P5为潜在的脏页。重做阶段按顺序重新应用所有更新，撤销阶段按逆序撤销T1和T3的操作。 mermaid格式流程图如下： ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px; classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A([开始]):::startend --> B(分析阶段):::process B --> C(识别脏页和活跃事务):::process C --> D(重做阶段):::process D --> E(从适当点重复操作):::process E --> F(撤销阶段):::process F --> G(撤销未提交事务操作):::process G --> H([结束]):::startend ``` #### 3. 日志（Log） 日志有时也称为轨迹或日志文件，是DBMS执行操作的历史记录。物理上，日志是存储在稳定存储中的记录文件，通过在不同磁盘（可能在不同位置）维护两个或多个副本，确保其在崩溃后仍可存活。 日志的最新部分称为日志尾部，保存在主内存中，并定期强制写入稳定存储。每个日志记录都有一个唯一的日志序列号（LSN），可通过LSN在一次磁盘访问中获取日志记录，且LSN应按单调递增顺序分配。 对于以下操作会写入日志记录： - **页面更新**：修改页面后，将更新类型的记录追加到日志尾部，并将页面的pageLSN设置为更新日志记录的LSN。 - **提交**：事务决定提交时，强制写入包含事务ID的提交类型日志记录，事务在其提交日志记录写入稳定存储的瞬间被视为已提交。 - **中止**：事务中止时，将包含事务ID的中止类型日志记录追加到日志中，并启动该事务的撤销操作。 - **结束**：事务中止或提交后，完成所有额外步骤后，将包含事务ID的结束类型日志记录追加到日志中。 - **撤销更新**：撤销事务的更新时，会写