Oracle实例恢复中先执行\_analysis阶段再执行redo阶段；\_analysis快速扫描日志元数据确定需恢复范围及low RBA，redo阶段据此精准重放已提交和部分未提交的物理变更以保障持久性。

数据库崩溃后，恢复过程中的 _analysis 阶段和 redo 阶段是 Oracle 实例恢复（Instance Recovery）的核心环节，它们共同确保数据的一致性和持久性。这两个阶段不是并行执行，而是严格按序进行：先分析（_analysis），再重做（redo），最后才是回滚（undo）。

_analysis 阶段：定位需要恢复的范围

该阶段本质是一次“快速扫描”，不修改数据文件，只读取控制文件和联机重做日志（online redo logs），目的是确定：

• 哪些数据文件处于“不一致”状态（例如，检查点位置落后于日志中最新变更）
• 从哪个日志序列号和偏移量开始应用重做（即确定 low RBA —— Redo Byte Address）
• 哪些事务在崩溃时尚未提交，哪些已提交但尚未写入数据文件

Oracle 会利用检查点信息（来自控制文件）与重做日志头对比，快速圈定需处理的日志范围。这个阶段耗时通常很短，因为只解析日志元数据，不解析具体变更内容。

redo 阶段：重放已提交但未写入的数据变更

在 _analysis 明确起点后，redo 阶段开始顺序读取重做日志（包括归档日志，若启用介质恢复），逐条应用其中的物理变更向量（physical change vectors）到数据块上。

• 只重做已提交事务的更改（commit 记录在日志中即可，无需等待 DBWn 写盘）
• 也重做未提交事务的部分更改（因为这些更改可能已被 DBWn 提前刷入数据文件）
• 所有操作均在 buffer cache 中进行，不直接写磁盘；后续由 DBWn 按需写出

这一阶段保障的是 持久性（Durability）：只要事务成功 commit，其修改就一定能通过重做日志重建出来。

注意：redo 不等于“重做所有日志”

Oracle 并非从日志开头一路重放到结尾。它依据 _analysis 阶段算出的 low RBA 和 checkpoint position，精准截取需应用的日志片段。例如：

• 如果最近一次完全检查点（checkpoint）位于日志 #100 的位置 X
• 而崩溃时最新的日志写入点在 #102 的位置 Y
• 那么 redo 阶段只会处理从 X 到 Y 覆盖的所有日志内容

跳过更早日志，既提升恢复速度，也避免重复或冲突操作。

与 undo 阶段的关系

redo 完成后，数据块可能包含未提交事务的“脏”修改。此时才进入 undo 阶段：使用回滚段（undo segments）中的前镜像（before image），将这些未提交的更改逻辑撤销，使数据库回到一致的事务边界状态。因此，redo 保证不丢数据，undo 保证不乱数据。