当前位置：首页 > news >正文

【数据库】Oracle学习笔记整理之六：ORACLE体系结构 - 重做日志文件与归档日志文件（Redo Log Files Archive Logs）

news 2025/8/21 7:25:33

ORACLE体系结构 - 重做日志文件与归档日志文件（Redo Log Files & Archive Logs）

在ORACLE数据库体系结构中，数据的安全性和可靠性至关重要，而重做日志文件与归档日志文件正是保障这一点的核心组成部分。它们如同数据库的“黑匣子”，记录着数据的每一次变更，在数据库遭遇故障时，能起到关键的恢复作用。

重做日志通过实时记录物理变更保障事务持久性，是崩溃恢复和实例恢复的基础，确保已提交事务不丢失；
归档日志通过保留历史日志扩展了恢复能力，支持时间点恢复、联机备份和高可用方案，是生产环境数据安全的核心保障。

在这里插入图片描述

一、核心概念与原理

在这里插入图片描述

1. 重做日志文件（Redo Log Files）

（1）概述

重做日志文件是Oracle数据库必须存在的核心文件，其核心功能是记录所有数据变更操作（包括DML和DDL），为数据库的崩溃恢复、事务持久性提供底层支持。

关键属性	说明
必要性	✅ 必须存在，数据库启动和运行的基础
核心作用	记录数据变更，支持崩溃恢复和事务持久性
关键特性	至少两组，循环写入；每组可包含多个镜像成员（防止单点故障）

（2）原理

核心原理：变更数据捕获与持久化
根本目的是确保所有已提交事务对数据库的更改不会丢失，即使发生实例崩溃、断电等故障也能恢复。
记录内容——“重做”信息
重做日志记录的是物理更改（而非逻辑SQL语句），即重建数据块修改所需的最小信息，包括：
- 数据块的插入、更新、删除操作；
- 撤销/回滚段（Undo Segments）数据块的更改（撤销数据本身也受重做保护）；
- 数据字典的更改（如表、列定义修改）；
- 段（Segments）和区段（Extents）的元数据操作（创建/修改/删除）；
- 某些直接路径操作（如APPEND提示）的可选日志记录；
- 事务提交记录（Commit Record）——标志事务永久性生效的关键信息。
写入时机与流程
数据变更的日志记录需经过“内存缓冲→磁盘持久化”的流程，严格遵循先写日志（Write-Ahead Logging, WAL） 原则（数据块修改前，对应的重做记录必须先写入磁盘）：
- 用户进程执行DML/DDL时，服务器进程先在PGA（进程私有内存）生成重做记录；
- 触发以下条件时，服务器进程将PGA中的重做记录复制到重做日志缓冲区（共享内存）：
  - 事务提交（COMMIT）；
  - 日志缓冲区填充1/3或达到1MB；
  - DBWn进程写入脏缓冲区前；
  - 每3秒超时。
- LGWR（日志写入器） 进程将日志缓冲区内容写入联机重做日志文件，触发时机包括：
  - 用户显式提交事务（COMMIT需等待LGWR写入完成才返回成功）；
  - 日志缓冲区填充1/3或达到1MB；
  - 每3秒超时；
  - DBWn写入脏缓冲区前；
  - 发生日志切换（Log Switch）。
循环工作机制
数据库至少需要2组重做日志文件（建议3组以上），LGWR按顺序写入当前组；当前组写满后触发日志切换，LGWR切换到下一组；最后一组写满后回绕到第一组覆盖（非归档模式）或归档后覆盖（归档模式）。

（3）特性

循环性
以组为单位循环写入，日志切换后自动切换到下一组，保证变更记录的连续性，避免单文件容量限制导致的操作中断。
多成员性
每组可包含多个成员（物理文件），成员间为镜像关系（内容完全相同），存储在不同磁盘。若一个成员损坏，其他成员仍可工作，防止单点故障导致日志丢失。
即时性
依赖LGWR进程的实时写入机制，事务提交时立即将重做记录写入磁盘，确保已提交事务的持久性（ACID特性中的Durability）。
与检查点的联动性
日志切换会触发检查点（Checkpoint）：CKPT进程更新控制文件和数据文件头部的SCN（系统变更号），通知DBWn将缓冲区中早于该SCN的脏块写入数据文件，减少实例恢复时间。

（4）作用

保障事务持久性
是ACID特性中“持久性”的核心保障：事务提交时，LGWR将包含提交记录的重做日志写入磁盘，即使提交后立即崩溃，重启时仍可通过日志恢复该事务。
支持数据库恢复
- 实例恢复（崩溃恢复）：实例异常终止后重启时，SMON进程利用重做日志前滚（应用所有已提交事务的变更）和回滚（撤销未提交事务的变更），使数据库恢复到一致性状态。
- 介质恢复：数据文件损坏时，还原备份后，通过重做日志（结合归档日志）前滚到故障前状态。
支撑高可用方案
- Data Guard：主库重做日志通过LGWR/ARCn传输到备库，备库应用日志保持同步；
- 逻辑复制（如GoldenGate）：通过解析重做日志获取逻辑变更，实现跨库数据同步。
数据审计基础
可通过LogMiner工具分析重做日志，提取历史变更信息（如“谁在何时修改了某行数据”），用于审计或数据修复。

2. 归档日志文件（Archive Logs）

（1）概述

归档日志文件（Archive Log Files）是在线重做日志文件在被覆盖之前的完整副本，由Oracle后台进程ARCn（归档进程）自动或按需创建，仅在数据库处于ARCHIVELOG模式时生成。

来源：当在线重做日志组写满或发生日志切换时，若数据库处于ARCHIVELOG模式，ARCn进程会将“非活动”的重做日志文件复制到指定目的地（磁盘、ASM、备用库等），生成归档日志。
核心目的：永久保存数据库变更历史，突破在线重做日志的循环覆盖限制，支撑时间点恢复、介质故障恢复、Data Guard同步等关键能力。

关键属性	说明
必要性	❌ 可选，仅在归档模式下生成
核心作用	保留历史变更记录，支持时间点恢复、联机备份和高可用方案
关键特性	依赖归档模式；可配置多路径存储；与重做日志形成连续的变更时间线

（2）原理

重做机制基础
基于Oracle“写前日志（WAL）”机制：所有数据修改先生成重做记录并写入在线重做日志，归档日志是这些在线日志的“历史快照”，确保变更记录的永久性。

ARCHIVELOG vs. NOARCHIVELOG 模式

模式	特点	适用场景
非归档模式	日志切换后直接覆盖旧日志，无归档文件；仅支持恢复到最后一次备份点	非关键开发/测试环境、只读库
归档模式	通过ARCn保留所有历史日志；支持时间点恢复、联机备份及Data Guard	生产环境、关键业务数据库

归档进程（ARCn）
- 负责将非活动在线重做日志复制到归档目标，可配置多个进程（ARC0_ARC9、ARCaARCt）提升并行度（通过LOG_ARCHIVE_MAX_PROCESSES设置）。
- 触发时机：监听日志切换事件，在在线日志变为“非活动”后立即执行归档。
- 操作流程：读取在线日志内容→写入归档目标→更新控制文件及V$ARCHIVED_LOG视图→标记在线日志为“可覆盖”。
归档日志序列与时间线
- 序列（Sequence）：每个归档日志有唯一且递增的序列号，即使数据库重启也不会重置，是恢复时按顺序应用的关键标识。
- 时间线（Timeline）：在OPEN RESETLOGS或Data Guard故障切换后，数据库开启新时间线，归档日志通过标识符（如%r）区分不同时间线，避免恢复时混淆。

（3）特性

归档依赖性
仅在ARCHIVELOG模式下生成，由ARCn进程自动创建（10g+默认自动归档），非归档模式下无此文件。
完整性与连续性
- 是在线重做日志的完整复制，包含从起始SCN到结束SCN的所有变更记录；
- 序列号必须连续，缺失任何一个会导致后续恢复中断（可通过V$ARCHIVED_LOG视图验证连续性）。
只读性
生成后内容固定不变，具有只读属性，确保恢复时的准确性。
可配置性
- 多目标归档：通过LOG_ARCHIVE_DEST_n（n=1…31）配置最多31个目的地，支持本地磁盘、ASM、远程备库等，可设置MANDATORY（必须成功）或OPTIONAL（可选成功）。
- 命名规范：通过LOG_ARCHIVE_FORMAT自定义格式，默认包含线程号（%t）、序列号（%s）、时间线ID（%r），如arch_%t_%s_%r.arc。
- 压缩与加密：10g R2+支持归档时压缩（LOG_ARCHIVE_COMPRESSION），节省存储空间；结合TDE可加密归档日志（LOG_ARCHIVE_ENCRYPTION），增强安全性。
生命周期可管理性
可通过备份、删除、迁移等操作管理，需根据存储容量和业务需求规划保留周期（如保留7天用于恢复）。
多场景适配性
- 分片：超大在线日志可自动分割为多个归档片段，便于传输和管理；
- 延迟应用：Data Guard环境中可配置备库延迟应用归档日志，用于逻辑错误补救；
- 多租户支持：CDB环境中归档日志包含所有PDB的变更，通过CON_ID区分不同容器。

（4）作用

数据恢复的基石
- 完全恢复：介质故障（如磁盘损坏）后，通过全量备份+备份后所有归档日志+在线日志，可恢复到故障前状态，实现零数据丢失。
- 时间点恢复（PITR）：精确恢复到任意时间点（如误删除数据后），依赖归档日志“回放”从备份到目标时间点的所有变更。
- 不完全恢复：当归档日志缺失时，可恢复到缺失日志之前的时间点，需通过OPEN RESETLOGS开启新时间线。
高可用性与容灾（Data Guard）
是Data Guard的核心：主库归档日志传输到物理备库后，由MRP进程应用实现块级同步；传输到逻辑备库后，由LSP进程解析为SQL并执行实现逻辑同步，支持切换/故障转移。
高效备份策略（RMAN）
- 是增量备份的基础：增量备份仅捕获变更数据块，需结合归档日志解决“模糊块”问题，确保恢复一致性。
- 支持“增量更新备份”：通过应用增量备份和归档日志，快速生成接近当前的完整数据副本。
日志挖掘（LogMiner）
通过DBMS_LOGMNR包解析归档日志，提取SQL语句和事务信息，用于审计用户操作、诊断问题、执行事务级回滚等。

二、关联与协同

重做日志与归档日志共同构成Oracle的日志体系，二者紧密关联且分工协作：

源与派生关系
归档日志是重做日志的“副本”，无重做日志则无归档日志；重做日志是实时变更记录，归档日志是历史变更的永久存储。
时间序列连续性
重做日志按SCN顺序循环记录，归档日志按日志切换顺序依次生成，二者共同形成完整的变更时间线（从数据库创建到当前）。
恢复协作性
介质恢复或时间点恢复时，需先还原备份，再应用备份后到目标时间点的归档日志，最后应用目标时间点后的重做日志，三者结合实现完整恢复。

三、故障恢复

1. 实例恢复与崩溃恢复

触发场景：实例崩溃（如shutdown abort、断电）后重启。
核心过程：
- 前滚：Oracle自动从最后一次检查点SCN开始，应用重做日志中所有已提交事务的变更，还原数据到崩溃前状态；
- 回滚：利用撤销段信息（受重做日志保护），撤销崩溃时未提交的事务，确保数据一致性。
日志角色：以重做日志为主，归档日志在需要恢复到更早时间点的扩展场景中补充使用。

2. 介质故障恢复

触发场景：数据文件、控制文件等因磁盘损坏、文件丢失导致的故障。
核心过程：
- 还原备份：使用RMAN或用户管理的备份还原受损/丢失的文件；
- 应用日志：执行RECOVER DATAFILE '<文件路径>'或RECOVER DATABASE，按顺序应用备份后生成的归档日志和当前重做日志，将文件前滚到故障前状态。
日志角色：归档日志负责还原备份后到故障前的大部分变更，重做日志补充故障前未归档的最新变更。

3. 时间点恢复（PITR）

触发场景：误删除数据、误操作等需恢复到特定时间点的场景。
核心过程：
- 还原全量备份：将数据库还原到mount状态；
- 指定恢复终点：执行RECOVER DATABASE UNTIL TIME 'YYYY-MM-DD HH24:MI:SS'（或UNTIL SCN/SEQUENCE）；
- 应用日志：Oracle自动应用从备份时间点到目标时间点的归档日志，若有未归档的重做日志也会自动应用；
- 重置日志打开：用ALTER DATABASE OPEN RESETLOGS打开数据库，重置日志序列号。
日志角色：归档日志是时间点恢复的核心，提供从备份到目标时间点的完整变更记录，重做日志补充目标时间点前的最新变更。

4. 日志文件损坏的应对

重做日志损坏
- 非活动成员损坏：删除损坏成员（ALTER DATABASE DROP LOGFILE MEMBER '<路径>'），添加新成员（ALTER DATABASE ADD LOGFILE MEMBER '<路径>' TO GROUP <组号>）；
- 当前/活动日志损坏：尝试ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP <组号>（可能丢失数据）；失败则需还原最近备份，执行不完全恢复（RECOVER DATABASE UNTIL CANCEL）后用RESETLOGS打开。
归档日志损坏或丢失
- 影响：若丢失的归档日志在恢复链中，后续恢复无法进行，只能恢复到丢失日志之前的时间点。
- 恢复方法：
  - 从备份还原：RESTORE ARCHIVELOG SEQUENCE <序列号>；
  - 从冗余目标复制：若配置多归档目标，从其他目标复制完好文件；
  - Data Guard补缺口：主库向备库重传缺失日志（RECOVER ... FROM SERVICE）；
  - 不完全恢复（最后手段）：恢复到丢失日志前的SCN，用OPEN RESETLOGS打开（丢失后续数据）。
- 预防措施：配置多归档目标（本地+远程）、定期备份归档日志、启用校验和（DB_BLOCK_CHECKSUM）。
归档进程（ARCn）故障
- 现象：归档中断，数据库因无法覆盖未归档日志而挂起，告警日志报ORA-00257等错误。
- 恢复：清理归档目标空间、修复权限/网络问题、重启ARCn（ALTER SYSTEM ARCHIVE LOG STOP/START）；必要时重启实例。
归档目标空间不足
- 应急处理：删除已备份的旧归档（DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'）、扩充磁盘空间、临时添加新归档目标。
- 预防：监控空间使用率（V$RECOVERY_AREA_USAGE）、自动清理脚本、合理规划容量。
Data Guard传输/应用延迟（GAP）
- 诊断：通过V$ARCHIVE_DEST_STATUS（主库）和V$MANAGED_STANDBY（备库）查看延迟和缺口。
- 恢复：手动注册缺失日志（ALTER DATABASE REGISTER LOGFILE）、自动补缺口（RECOVER ... FROM SERVICE）；优化网络或备库应用性能。

四、管理

1. 重做日志文件的管理

创建与配置
- 创建日志组：ALTER DATABASE ADD LOGFILE GROUP 3 ('/disk1/log3a.log', '/disk2/log3b.log') SIZE 100M;（每组2个成员，分存不同磁盘）；
- 添加成员：ALTER DATABASE ADD LOGFILE MEMBER '/disk3/log1c.log' TO GROUP 1;。
监控与维护
- 关键视图：V$LOG（日志组状态、序列号）、V$LOGFILE（成员路径、状态）；
- 若日志切换频繁（如每分钟多次），需增大日志文件大小（建议500M-2G）；
- 发现损坏成员时，及时删除并重建，确保组内成员完整性。
切换与清理
- 手动切换：ALTER SYSTEM SWITCH LOGFILE;（用于备份前强制生成检查点）；
- 清理日志：ALTER DATABASE CLEAR LOGFILE GROUP 2;（仅用于非活动日志，需谨慎）。

2. 归档日志文件的管理

切换归档模式

-- 开启归档模式
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
-- 验证：archive log list; 或 SELECT log_mode FROM v$database;

配置归档目标与格式

多路径配置（推荐）：

-- 本地强制归档（失败300秒重试）
ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/archive MANDATORY REOPEN=300';
-- 远程归档到备库（通过TNS服务名）
ALTER SYSTEM SET log_archive_dest_2='SERVICE=standby_db MANDATORY';

文件名格式：ALTER SYSTEM SET log_archive_format='%t_%s_%r.arc';（%t=线程号，%s=序列号，%r=RESETLOGS ID）。

备份与清理
- 用RMAN备份并删除已备份归档：BACKUP ARCHIVELOG ALL DELETE INPUT;；
- 手动删除过期归档：DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';（保留最近7天）；
- 按保留策略清理：DELETE OBSOLETE;（根据RMAN配置的保留策略删除过期文件）。
监控
- 关键视图：
  - V$ARCHIVED_LOG：归档日志详情（序列号、时间戳、大小、备份状态）；
  - V$ARCHIVE_DEST_STATUS：归档目标状态、错误信息、传输延迟；
  - V$ARCHIVE_PROCESSES：ARCn进程状态（BUSY/STOPPED）；
  - V$RECOVERY_AREA_USAGE：闪回恢复区（FRA）空间使用情况（若归档到FRA）。
- 告警日志：记录所有归档相关事件（切换、失败、进程异常等），是故障诊断的核心依据。
最佳实践
- 生产库强制启用ARCHIVELOG模式；
- 配置至少2个归档目标（本地+远程/不同磁盘）实现冗余；
- 启用归档压缩（LOG_ARCHIVE_COMPRESSION=ENABLE）节省空间（评估CPU开销）；
- RAC环境中，归档日志需包含线程号（%t），存储在共享位置（如ASM）；
- 定期验证备份有效性（RESTORE ... VALIDATE），确保归档日志可恢复。

五、性能与故障调优

1. 重做日志相关性能调优

日志文件配置
- 大小：避免过小（频繁切换导致log file switch等待）或过大（恢复时间长），建议500M-2G；
- 组数：至少3组，避免LGWR等待归档或检查点（LOG FILE SWITCH (ARCHIVING NEEDED)等待事件）。
I/O优化
- 日志文件放在高速磁盘（如RAID 1/10），与数据文件、归档目标分离，减少I/O竞争；
- 配置足够的LGWR进程（默认1个，无需手动调整），避免log buffer space等待。
事务优化
- 避免频繁小事务（减少LGWR写入次数），采用批量提交；
- 非关键操作可使用NOLOGGING（如CTAS），但需注意：此类操作无法通过日志恢复，需重新执行。

2. 归档日志相关性能调优

归档性能优化
- 归档目标放在高速磁盘，与重做日志、数据文件分离，减少I/O竞争；
- 配置足够的ARCn进程（log_archive_max_processes，默认4，最多10），应对高并发归档需求。
常见故障处理
- 归档失败：原因包括归档路径满、权限错误或ARCn进程异常；解决方法为清理归档空间、修复权限或重启ARCn（ALTER SYSTEM SET log_archive_max_processes=4;）。
- 日志切换等待：LOG FILE SWITCH (ARCHIVING NEEDED)表明ARCn归档慢，需增加ARCn进程或优化归档目标I/O。
- Data Guard同步延迟：优化网络带宽、启用实时应用（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE）、调整备库并行应用参数（PARALLEL_MAX_SERVERS）。