Oracle Redo Log 详解：DBA 需要了解的一切

什么是 Oracle Redo Log 以及它为何重要

Oracle 重做日志记录对数据库所做的每一项更改。当用户运行 INSERT、UPDATE 或 DELETE 时，Oracle 不会直接将更改写入磁盘。它会先记录更改，然后将其刷新到重做日志文件中。

如果实例崩溃，Oracle 会在下次启动时重放这些记录的更改，恢复每个已提交的事务。这是 ACID 合规性中持久性的基础。

Oracle 维护两种类型：

• 在线重做日志 — Oracle 以循环方式写入的活动文件
• 归档重做日志 — 已填充在线日志的离线副本，用于长期恢复

在深入探讨之前，这里有四个术语，您将在本指南中频繁看到：

• 日志组： 一个或多个相同重做日志文件的集合。Oracle 同时写入一个组的所有成员。
• 日志成员： 组内的单个物理文件。
• 日志切换： Oracle 完成填充当前日志组并移动到下一个可用日志组的时刻。
• SCN（系统更改号）： 分配给每个事务的唯一、不断递增的编号。Oracle 使用它在恢复操作中保持数据一致性。

Oracle Redo Log 文件：结构与多路复用

重做日志文件是磁盘上预分配的固定大小文件。与数据文件不同，重做日志是循环的。当最后一个组写满时，Oracle 循环回第一个组并覆盖它，但前提是该组已被归档且其更改已写入数据文件（已执行检查点）。

Oracle 将重做日志文件组织成两层结构：组和成员。组是由一个或多个相同的成员文件组成的逻辑单元。日志写入进程（LGWR）同时将相同的重做条目写入当前组中的每个成员。

多路复用 意味着将同一组的多个成员存储在不同的物理磁盘上。如果一个磁盘发生故障并损坏了一个成员文件，只要该组中至少有一个成员保持可读，Oracle 就会继续运行。如果没有多路复用，丢失单个重做日志文件就可能导致整个数据库宕机。

日志文件状态解读

当您查询 V$LOG 时，每个组将显示以下四种状态之一：

如何查看您的重做日志配置

要查看您的组、成员、大小和当前状态：

SELECT 
    a.GROUP#, 
    a.STATUS, 
    b.MEMBER, 
    a.BYTES/1024/1024 AS SIZE_MB
FROM V$LOG a 
JOIN V$LOGFILE b ON a.GROUP# = b.GROUP#
ORDER BY a.GROUP#;

如何添加和删除重做日志组和成员

添加新组（为多路复用，在独立磁盘上创建两个成员）：

ALTER DATABASE ADD LOGFILE GROUP 4
('/u01/app/oracle/oradata/REDO/log4a.rdo',
 '/u02/app/oracle/oradata/REDO/log4b.rdo') SIZE 512M;

向现有组添加成员：

ALTER DATABASE ADD LOGFILE MEMBER
'/u02/app/oracle/oradata/REDO/log1b.rdo' TO GROUP 1;

删除组：

ALTER DATABASE DROP LOGFILE GROUP 4;

如何查找和管理 Oracle Redo Log 文件位置

为重做日志文件找到正确的位置归结为两个优先事项：性能和冗余。

如果您使用 Oracle 托管文件（OMF），Oracle 会根据 DB_CREATE_ONLINE_LOG_DEST_n 参数自动处理命名和放置。但无论文件如何放置，有一条规则始终适用：切勿将同一组的成员存储在同一个物理磁盘上。 如果两个成员都位于同一个故障卷上，多路复用就无法提供任何保护。始终将成员分散到不同的挂载点、存储控制器或 ASM 磁盘组中。

如何检查 Oracle Redo Log 文件位置

查询 V$LOGFILE 以查看每个成员的存储位置以及它是位于常规文件系统还是 ASM 中：

SELECT 
    GROUP#, 
    TYPE, 
    MEMBER 
FROM V$LOGFILE 
ORDER BY GROUP#;

如何将 Redo Log 文件移动到新位置

在将日志迁移到更快的存储或纠正放置问题时，请使用以下步骤。下面的重命名方法适用于所有 Oracle 版本。

1. 干净地关闭数据库，以便所有重做数据刷新到磁盘：

SHUTDOWN IMMEDIATE;

2. 在操作系统层面将文件复制到新位置，使用 cp（Linux）或 copy（Windows）。Oracle 不会为您移动文件 — 此步骤必须手动完成。

3. 挂载数据库：

STARTUP MOUNT;

4. 使用新路径更新控制文件：

ALTER DATABASE RENAME FILE '/old_disk/log1a.rdo' TO '/new_disk/log1a.rdo';
ALTER DATABASE RENAME FILE '/old_disk/log1b.rdo' TO '/new_disk/log1b.rdo';

5. 在打开数据库之前验证路径是否已更新：

SELECT GROUP#, TYPE, MEMBER FROM V$LOGFILE ORDER BY GROUP#;

6. 打开数据库：

ALTER DATABASE OPEN;

Oracle Redo Log 大小与切换频率：全面解析

日志大小和切换频率直接相关。重做日志的大小决定了 Oracle 在必须切换到下一个组之前可以记录多少更改数据。每次切换都会触发检查点，强制数据库写入进程（DBWn）将内存中修改的数据刷新到磁盘。

当日志太小时，切换过于频繁。持续的检查点会造成 I/O 瓶颈，通常会在等待事件中显示为“log file switch (checkpoint incomplete)”。

目标是在峰值负载期间每 15 到 30 分钟切换一次。比这更频繁是日志大小不足的明确信号。

如何检查当前切换频率

查询 V$LOG_HISTORY 以查看过去七天内每小时发生的切换次数：

SELECT 
    TRUNC(FIRST_TIME, 'HH') AS HOUR,
    COUNT(*) AS SWITCHES
FROM V$LOG_HISTORY
WHERE FIRST_TIME > SYSDATE - 7
GROUP BY TRUNC(FIRST_TIME, 'HH')
ORDER BY 1;

查找切换次数较多的小时。这些是您的峰值时段，也是您配置大小的参考点。

如何根据工作负载调整 Redo Log 大小

使用以下公式作为起点：

峰值重做速率（MB/分钟） × 30 分钟 = 理想日志大小

对于标准 OLTP 工作负载，500 MB 到 1 GB 是合理的基线。对于有大量批处理作业或日终处理的数据库，请根据峰值负载（而非日平均值）来配置大小。根据平均值配置意味着您的数据库将在性能最关键的时候恰好停滞。

一个真实示例：一个使用 200 MB 日志的数据库，在夜间批处理负载期间每小时发生 456 次切换。将日志大小增加到 22 GB 后，“log file switch (checkpoint incomplete)”等待事件完全从 AWR 前几位等待事件中消失，批处理窗口缩短了 40%。

如何调整 Redo Log 文件大小

您无法直接调整现有日志文件的大小。过程是：添加更大的组，循环使用它们，然后删除旧组。

1. 按目标大小添加新组：

ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/redo04.log') SIZE 2G;
ALTER DATABASE ADD LOGFILE GROUP 5 ('/u01/app/oracle/oradata/redo05.log') SIZE 2G;
ALTER DATABASE ADD LOGFILE GROUP 6 ('/u01/app/oracle/oradata/redo06.log') SIZE 2G;

2. 强制日志切换，使 Oracle 移动到新组：

ALTER SYSTEM SWITCH LOGFILE;

3. 一旦旧组达到 INACTIVE 状态，删除它们：

ALTER DATABASE DROP LOGFILE GROUP 1;

4. 对每个剩余的旧组重复步骤 3。

ARCHIVELOG 模式、恢复以及 Redo Log 何时拯救您的数据库

每个 Oracle 数据库都以两种模式之一运行：NOARCHIVELOG 或 ARCHIVELOG。

在 NOARCHIVELOG 模式下，已填充的重做日志会被直接覆盖。恢复只能到最后一次完整备份为止——之后的任何数据都会丢失。

在 ARCHIVELOG 模式下，Oracle 在重用每个重做日志之前会保存其永久副本。这允许您恢复旧备份并重放归档日志，以便在故障发生的那一刻进行恢复。对于任何生产数据库来说，ARCHIVELOG 模式是不可或缺的。

崩溃恢复如何工作

当实例崩溃并重新启动时，Oracle 自动运行两步恢复过程：

1. 前滚： Oracle 将所有重做日志更改应用到数据文件，使它们与崩溃时内存中的内容同步。
2. 回滚： Oracle 识别出任何正在进行但从未提交的事务，并将其撤销以恢复一致状态。

无需手动干预。此过程在数据库打开之前完成。

如何检查您的模式并启用 ARCHIVELOG

检查您当前的归档状态：

ARCHIVE LOG LIST;

如果输出显示“No Archive Mode”，请按照以下步骤启用它：

1. 关闭数据库：

SHUTDOWN IMMEDIATE;

2. 挂载数据库：

STARTUP MOUNT;

3. 启用 ARCHIVELOG 模式：

ALTER DATABASE ARCHIVELOG;

4. 打开数据库：

ALTER DATABASE OPEN;

常见重做日志问题及解决方法

当 Oracle Redo Log 不够用时：使用 i2Backup 的企业级备份

重做日志是 Oracle 的第一道防线。它们自动处理崩溃恢复，并确保在实例意外宕机时不会丢失任何已提交的事务。

但重做日志有其局限性。它们无法从意外数据删除、永久性磁盘故障或已经检查点到数据文件的损坏中恢复。它们也无法提供跨多个数据库管理备份策略的集中方式。

对于这些场景，您需要一个专用的备份解决方案。i2Backup 是一个企业级备份平台，旨在覆盖重做日志无法覆盖的领域。

i2Backup 关键特性

• 实时和计划数据库备份： i2Backup 支持独立 Oracle 实例和集群环境（包括 RAC 和 ADG）。它持续捕获重做日志和归档日志，使 RPO 接近为零。时间点恢复允许您将数据库恢复到任何特定时刻，而不仅仅是最后一个备份检查点。
• 表级恢复： 除了完整数据库恢复外，i2Backup 还支持表级备份和恢复——在意外删除或损坏后只需恢复部分数据时非常有用。
• 灵活的备份目标： 备份可以同时发送到本地存储、NAS 或云目标，消除备份基础设施中的单点故障。
• 集中管理： 基于 Web 的控制台允许您跨多个数据库主机调度、监控和管理备份任务，无需在工具之间切换。

完整的数据保护堆栈

对于还需要高可用性或实时复制的 Oracle 环境，英方软件提供了两款互补产品：

• i2Availability 提供生产服务器和备用服务器之间的实时数据复制和自动故障转移，在硬件故障期间保持服务运行。
• i2Stream 处理跨异构平台的数据库复制和同步，支持 Oracle、MySQL、PostgreSQL 等。

与 i2Backup 一起，这些工具涵盖了从实例级崩溃恢复到跨平台灾难恢复的完整数据保护需求。

您可以点击按钮免费试用英方软件的灾备解决方案。

结论

Oracle 重做日志是数据库持久性的基础。它们记录每个已提交的更改，启用自动崩溃恢复，并且在正确配置大小时，可以让您的数据库运行而不会出现性能瓶颈。

本指南的关键要点：

• 将重做日志成员多路复用到不同的磁盘上，以消除单点故障
• 目标是在峰值负载下每 15 到 30 分钟切换一次日志；如果切换更频繁，说明您的日志大小不足
• 始终在生产数据库上运行 ARCHIVELOG 模式
• 根据峰值工作负载（而非日平均值）配置日志大小

也就是说，重做日志不是备份策略。它们保护免受实例崩溃的影响，但不能防止意外删除、硬件故障或跨多个数据库管理恢复的需要。为此，像英方软件的 i2Backup 这样的专用解决方案填补了这一空白——提供持续的 Oracle 备份、时间点恢复以及跨环境的集中管理。