【故障案例】一次 RMAN 恢复失败的教训 — 归档日志中断导致不完全恢复

本文是「每周一个 Oracle 故障案例」系列第 2 篇。这个案例揭示了一个常见但容易被忽视的问题：你以为备份没问题，直到真正需要恢复的那天。

故障背景

某公司的 ERP 数据库（Oracle 19c 单实例），磁盘阵列故障导致一个数据文件损坏。DBA 决定用 RMAN 恢复该文件。

备份策略：

每周日全备
每天增量备份
归档日志备份"也做了"

看起来一切正常，直到恢复的时候……

恢复过程

尝试恢复

SQL

1RMAN> RESTORE DATAFILE 7;
2RMAN> RECOVER DATAFILE 7;

报错：

SQL

1RMAN-06054: media recovery requesting unknown archived log for thread 1
2with sequence 456 and starting SCN of 12345678

翻译：RMAN 需要归档日志 sequence#456，但找不到。

检查归档日志

SQL

1-- 检查 RMAN 目录中的归档日志记录
2RMAN> LIST ARCHIVELOG ALL;
3
4-- 发现：
5-- sequence 450-454 ✓ 存在
6-- sequence 455     ✗ 缺失
7-- sequence 456     ✗ 缺失
8-- sequence 457-460 ✓ 存在

归档日志出现了 GAP（中断）！sequence 455-456 丢失了。

排查 GAP 原因

Bash

1# 查看 Alert Log
2
3> **本章目标**：掌握本章核心知识点
4> **前置要求**：完成前序章节学习
5> **预计时长**：60 分钟
6
7grep -i "archiv\|ORA-" alert_orcl.log | grep "2026-04-20"
8
9# 发现：4 月 20 日凌晨 2 点
10# ORA-19504: failed to create file "/arch/orcl/arch_455.arc"
11# ORA-27044: unable to write the header block of file
12# ORA-19502: write error on file, block number 1

根因：归档目录磁盘空间在 4 月 20 日凌晨满了，导致两个归档日志写入失败。当时 DBA 清理了磁盘空间后归档恢复正常，但没有注意到已经产生了 GAP。

尝试不完全恢复

既然完全恢复不可能了（GAP 意味着无法应用连续的 redo），只能做不完全恢复——恢复到 GAP 之前的时间点。

SQL

1-- 查看 sequence 454 的结束 SCN
2SELECT sequence#, first_change#, next_change#, first_time
3FROM v$archived_log
4WHERE sequence# = 454 AND dest_id = 1;
5
6-- 假设 next_change# = 12340000

SQL

1-- 不完全恢复到 GAP 之前
2RMAN> RUN {
3  SET UNTIL SCN 12340000;
4  RESTORE DATAFILE 7;
5  RECOVER DATAFILE 7;
6}
7SQL> ALTER DATABASE DATAFILE 7 ONLINE;

但是——这个文件最后一次全备是周日，GAP 发生在周三凌晨。这意味着周三凌晨到周五故障时间段内的数据全部丢失，大约 2.5 天的数据。

数据丢失影响评估

SQL

1-- 评估丢失数据量
2-- 恢复点（sequence 454 结束时间）：4/20 01:50
3-- 故障时间：4/22 10:30
4-- 数据丢失窗口：约 56 小时
5
6-- 检查受影响的表中有多少最近数据
7-- （从其他途径估算，比如应用日志）

最终，2.5 天的 ERP 业务数据需要从应用层导出的 CSV 报表中手工补录。

问题复盘

根因链

归档目录磁盘满 → 归档日志写入失败 → 产生 GAP ↓ DBA 清理空间后归档恢复 → 但未检查是否有 GAP ↓ 2 天后数据文件损坏 → RMAN 恢复需要缺失的归档日志 → 不完全恢复 → 数据丢失

三个关键疏忽

疏忽一：归档目录没有监控告警

SQL

1-- 应该做：监控 FRA 使用率
2SELECT
3    name,
4    ROUND(space_limit/1024/1024/1024, 1) AS limit_gb,
5    ROUND(space_used/1024/1024/1024, 1) AS used_gb,
6    ROUND(space_used/space_limit*100, 1) AS pct_used
7FROM v$recovery_file_dest;

疏忽二：归档日志备份后没有验证连续性

SQL

1-- 应该做：每天验证归档日志连续性
2SELECT thread#, sequence#,
3       sequence# - LAG(sequence#) OVER (ORDER BY sequence#) AS gap
4FROM v$archived_log
5WHERE dest_id = 1
6  AND first_time > SYSDATE - 7
7ORDER BY sequence#;
8-- 如果 gap > 1，说明有中断

疏忽三：没有定期做恢复演练

如果每季度做一次恢复演练，早就发现归档日志 GAP 的问题了。

预防措施

1. FRA 空间监控 + 自动清理

SQL

1-- 设置 FRA 告警
2BEGIN
3  DBMS_SERVER_ALERT.SET_THRESHOLD(
4    metrics_id   => DBMS_SERVER_ALERT.DB_RECOVERY_FILE_DEST_USED,
5    warning_operator  => DBMS_SERVER_ALERT.OPERATOR_GE,
6    warning_value     => '80',
7    critical_operator => DBMS_SERVER_ALERT.OPERATOR_GE,
8    critical_value    => '90',
9    observation_period => 1,
10    consecutive_occurrences => 1,
11    instance_name => NULL,
12    object_type   => DBMS_SERVER_ALERT.OBJECT_TYPE_SYSTEM,
13    object_name   => NULL
14  );
15END;
16/

2. 归档日志备份后验证

Bash

1# 在每日备份脚本末尾加入验证
2rman target / <<EOF
3CROSSCHECK ARCHIVELOG ALL;
4REPORT NEED BACKUP ARCHIVELOG ALL;
5EOF

3. RMAN 配置优化

SQL

1-- 自动备份控制文件（恢复时必需）
2RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
3
4-- 备份完成后验证
5RMAN> BACKUP VALIDATE DATABASE PLUS ARCHIVELOG;

4. 恢复演练清单

每季度至少做一次：

从最新备份恢复到测试环境
验证归档日志连续性
测试不完全恢复（指定时间点）
记录恢复耗时（评估 RTO）

总结

这个案例的核心教训：

备份的价值不在于"做了备份"，而在于"能成功恢复"。

问题	教训
归档日志 GAP	必须监控归档日志连续性
磁盘空间不足	FRA 使用率 80% 就要告警
发现问题没有深究	清理空间后应该检查是否有 GAP
没有恢复演练	每季度至少演练一次

这是「每周一个 Oracle 故障案例」系列的第 2 篇。关注公众号 DBA学习之路 获取更多案例。RMAN 备份恢复的完整学习路径请看 DBA 学习之路 Day 11-20 →