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 保证不乱数据。
