什么是 REDO LOG，它在 Oracle 数据库中的作用是什么？

REDO LOG（重做日志） 是 Oracle 数据库中一种关键的事务日志机制 ，用于记录数据库中所有数据变更操作 （如 INSERT、UPDATE、DELETE、DDL 等）所产生的"重做记录"（Redo Records）。它的核心作用是保障数据库的持久性（Durability）和崩溃恢复能力。

一、REDO LOG 的基本组成

在 Oracle 中，REDO LOG 由以下部分构成：

重做日志文件（Redo Log Files）
- 物理存储在磁盘上的文件（通常以 .log 结尾）；
- 分为联机重做日志 （Online Redo Log）和 归档重做日志（Archived Redo Log）；
- 联机日志是数据库运行时实时写入的日志；
- 归档日志是联机日志被填满后，由 ARCH 进程归档保存的副本（仅在归档模式下启用）。
重做日志组（Redo Log Groups）
- Oracle 至少需要 2 个重做日志组（推荐 3 个以上）；
- 每个组包含一个或多个成员（Member），实现冗余（多路复用）；
- 日志写入按组循环进行：LGWR（Log Writer）进程依次写入 Group 1 → Group 2 → Group 3 → 回到 Group 1......
LGWR 进程（Log Writer）
- 负责将 SGA 中的 Redo Buffer 内容写入磁盘上的联机重做日志文件；
- 触发写入的条件包括：事务提交（COMMIT）、每 3 秒、Redo Buffer 满 1/3、DBWn 写脏块前等。

二、REDO LOG 的核心作用

1. 保证事务的持久性（ACID 中的 D）

当用户执行 COMMIT 时，Oracle 并不立即把数据块写入数据文件；
而是先确保对应的 REDO 记录已写入磁盘日志文件；
即使随后发生断电或崩溃，只要 REDO LOG 存在，就能在重启时恢复该事务。

✅ 关键原则 ："日志先行"（Write-Ahead Logging, WAL）------任何数据块的修改必须先有对应的 REDO 记录落盘。

2. 支持实例恢复（Instance Recovery）

数据库异常关闭（如宕机）后重启时，SMON 进程会自动执行：
- 前滚（Roll Forward）：应用 REDO LOG 中未写入数据文件的已提交事务；
- 回滚（Roll Back）：撤销未提交的事务（利用 UNDO + REDO 中的信息）；
最终使数据库回到一致状态。

3. 支撑数据库备份与时间点恢复（PITR）

在 ARCHIVELOG 模式 下，REDO LOG 被归档保存；
结合全量备份 + 归档日志，可将数据库恢复到任意历史时间点（如误删表后恢复到删除前）。

4. 支持 Data Guard、GoldenGate 等高可用/复制技术

物理备库（Data Guard）通过应用主库传来的 REDO LOG 实现同步；
REDO 是 Oracle 实现实时数据复制的基础。

三、REDO LOG 与其他组件的关系

组件	与 REDO LOG 的关系
UNDO	UNDO 用于回滚和一致性读，但 UNDO 本身的修改也需要记录 REDO！
数据文件	数据文件更新可能滞后，REDO 确保变更不会丢失
CHECKPOINT	触发 DBWn 将脏块写入数据文件，并推进 REDO 的"检查点位置"，减少恢复时间

四、简单示例说明

sql 复制代码

UPDATE employees SET salary = 10000 WHERE id = 101;
COMMIT;

执行过程：

修改内存中的数据块（Buffer Cache）；
在 Redo Buffer 中生成重做记录（如："将 block X 的 offset Y 处从 A 改为 B"）；
执行 COMMIT → LGWR 立即将 Redo Buffer 中的相关记录写入磁盘 REDO LOG；
此时事务即视为"永久生效"，即使数据库立刻崩溃，重启后也能通过 REDO 恢复此更新。

总结

REDO LOG 是 Oracle 数据库的"黑匣子"，它：

记录所有数据变更；

确保已提交事务永不丢失；

是崩溃恢复、备份恢复、数据复制的基石；

必须合理配置大小、数量和归档策略，避免性能瓶颈（如"日志切换等待"）。

没有 REDO LOG，Oracle 就无法保证 ACID，也无法实现企业级高可用。