备份恢复 & 迁移5 分钟阅读
【故障案例】一次 RMAN 恢复失败的教训 — 归档日志中断导致不完全恢复
真实案例：数据文件损坏需要 RMAN 恢复，却发现归档日志有 GAP 无法完全恢复。复盘归档日志管理的常见疏忽，以及如何在不完全恢复中最大限度减少数据丢失。
2026年4月26日阅读—点赞—收藏—
oraclerman备份恢复归档日志故障案例
内容阅读
在知识库中专注阅读，并随时返回相关工具与课程
在知识库中专注阅读，并随时返回相关工具与课程
真实案例：数据文件损坏需要 RMAN 恢复，却发现归档日志有 GAP 无法完全恢复。复盘归档日志管理的常见疏忽，以及如何在不完全恢复中最大限度减少数据丢失。
本文是「每周一个 Oracle 故障案例」系列第 2 篇。这个案例揭示了一个常见但容易被忽视的问题：你以为备份没问题，直到真正需要恢复的那天。
某公司的 ERP 数据库（Oracle 19c 单实例），磁盘阵列故障导致一个数据文件损坏。DBA 决定用 RMAN 恢复该文件。
备份策略：
看起来一切正常，直到恢复的时候……
报错：
翻译：RMAN 需要归档日志 sequence#456，但找不到。
归档日志出现了 GAP（中断）！sequence 455-456 丢失了。
根因：归档目录磁盘空间在 4 月 20 日凌晨满了，导致两个归档日志写入失败。当时 DBA 清理了磁盘空间后归档恢复正常，但没有注意到已经产生了 GAP。
既然完全恢复不可能了（GAP 意味着无法应用连续的 redo），只能做不完全恢复——恢复到 GAP 之前的时间点。
但是——这个文件最后一次全备是周日，GAP 发生在周三凌晨。这意味着周三凌晨到周五故障时间段内的数据全部丢失，大约 2.5 天的数据。
最终，2.5 天的 ERP 业务数据需要从应用层导出的 CSV 报表中手工补录。
归档目录磁盘满 → 归档日志写入失败 → 产生 GAP ↓ DBA 清理空间后归档恢复 → 但未检查是否有 GAP ↓ 2 天后数据文件损坏 → RMAN 恢复需要缺失的归档日志 → 不完全恢复 → 数据丢失
疏忽一：归档目录没有监控告警
疏忽二：归档日志备份后没有验证连续性
疏忽三：没有定期做恢复演练
如果每季度做一次恢复演练，早就发现归档日志 GAP 的问题了。
每季度至少做一次：
这个案例的核心教训：
备份的价值不在于"做了备份"，而在于"能成功恢复"。
这是「每周一个 Oracle 故障案例」系列的第 2 篇。关注公众号 DBA学习之路 获取更多案例。RMAN 备份恢复的完整学习路径请看 DBA 学习之路 Day 11-20 →
1RMAN> RESTORE DATAFILE 7;2RMAN> RECOVER DATAFILE 7;1RMAN-06054: media recovery requesting unknown archived log for thread 12with sequence 456 and starting SCN of 123456781-- 检查 RMAN 目录中的归档日志记录2RMAN> LIST ARCHIVELOG ALL;34-- 发现：5-- sequence 450-454 ✓ 存在6-- sequence 455 ✗ 缺失7-- sequence 456 ✗ 缺失8-- sequence 457-460 ✓ 存在1# 查看 Alert Log23> **本章目标**：掌握本章核心知识点4> **前置要求**：完成前序章节学习5> **预计时长**：60 分钟67grep -i "archiv\|ORA-" alert_orcl.log | grep "2026-04-20"89# 发现：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 file12# ORA-19502: write error on file, block number 11-- 查看 sequence 454 的结束 SCN2SELECT sequence#, first_change#, next_change#, first_time3FROM v$archived_log4WHERE sequence# = 454 AND dest_id = 1;56-- 假设 next_change# = 123400001-- 不完全恢复到 GAP 之前2RMAN> RUN {3 SET UNTIL SCN 12340000;4 RESTORE DATAFILE 7;5 RECOVER DATAFILE 7;6}7SQL> ALTER DATABASE DATAFILE 7 ONLINE;1-- 评估丢失数据量2-- 恢复点（sequence 454 结束时间）：4/20 01:503-- 故障时间：4/22 10:304-- 数据丢失窗口：约 56 小时56-- 检查受影响的表中有多少最近数据7-- （从其他途径估算，比如应用日志）1-- 应该做：监控 FRA 使用率2SELECT3 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_used7FROM v$recovery_file_dest;1-- 应该做：每天验证归档日志连续性2SELECT thread#, sequence#,3 sequence# - LAG(sequence#) OVER (ORDER BY sequence#) AS gap4FROM v$archived_log5WHERE dest_id = 16 AND first_time > SYSDATE - 77ORDER BY sequence#;8-- 如果 gap > 1，说明有中断1-- 设置 FRA 告警2BEGIN3 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 => NULL14 );15END;16/1# 在每日备份脚本末尾加入验证2rman target / <<EOF3CROSSCHECK ARCHIVELOG ALL;4REPORT NEED BACKUP ARCHIVELOG ALL;5EOF1-- 自动备份控制文件（恢复时必需）2RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;34-- 备份完成后验证5RMAN> BACKUP VALIDATE DATABASE PLUS ARCHIVELOG;