Oracle Data Guard备库归档日志满导致同步中断的解决方法_Oracle

问题背景

某日收到业务反馈，数据库查询延迟增大，部分报表数据不准确。经排查发现，data guard 备库的归档日志目录已满，导致备库无法接收和应用新的归档日志，同步中断。

问题现象

1. 备库归档日志空间告警

登录备库，检查闪回恢复区使用情况：

select 
    name,
    space_limit / 1024 / 1024 / 1024 as total_gb,
    space_used / 1024 / 1024 / 1024 as used_gb,
    round((space_used / space_limit) * 100, 2) as pct_used
from v$recovery_file_dest;

结果：

指标	值	状态
总空间	20 gb	初始配置
已使用	19.93 gb	几乎占满
使用率	99.65%	⚠️ 危险阈值

2. 备库同步状态异常

select database_role, open_mode, protection_mode from v$database;

备库处于 mounted 状态，但日志应用进程停滞。

select process, status, sequence# from v$managed_standby;

mrp0 进程状态显示 wait_for_gap，表示等待归档日志。

根因分析

归档日志空间满的原因通常有以下几个：

原因	说明
闪回恢复区过小	初始配置仅为 20gb，远小于归档日志生成速度
未配置自动清理策略	归档日志被应用后未自动删除，长期累积导致空间不足
业务高峰期日志量激增	特定时段产生大量归档日志，超出日常估算

核心问题：闪回恢复区（fast recovery area，fra）空间不足，mrp 进程无法接收新的归档日志。

解决过程

第一阶段：清理归档日志（紧急恢复）

查看闪回恢复区目录结构，定位归档日志位置：

cd /app/oracle/fast_recovery_area/pdmdb1/pdmdb1
du -sh *

使用 rman 清理已被应用的历史归档日志：

rman target /

-- 删除已被应用且超过 7 天的归档日志
delete archivelog all completed before 'sysdate-7';

清理结果：

指标	清理前	清理后
使用率	99.65%	20.36%
已使用空间	19.93 gb	61.07 gb *
可用空间	0.07 gb	238.93 gb

*> 注：清理后闪回恢复区显示 61.07 gb，是因为归档日志从 99% 降到了正常范围，部分闪回日志仍保留。

第二阶段：恢复同步

清理空间后，重新启动备库的日志应用进程：

-- 取消当前日志应用
alter database recover managed standby database cancel;
-- 重新启动日志应用
alter database recover managed standby database using current logfile disconnect from session;

第三阶段：确认同步恢复

执行以下检查，确认同步已正常恢复：

-- 1. 确认无日志缺口
select * from v$archive_gap;
-- 2. 确认日志已应用
select thread#, max(sequence#) as last_applied 
from v$archived_log 
where applied='yes' 
group by thread#;
-- 3. 查看 mrp 进程状态
select process, status, sequence# from v$managed_standby;

确认结果：

检查项	结果	状态
`v$archive_gap`	`no rows selected`	✅ 无缺口
最新已应用日志	sequence# 56809	✅ 持续更新
数据文件时间戳	更新至当前时间	✅ 同步正常

第四阶段：扩容闪回恢复区（根治措施）

4.1 确认磁盘空间

df -h /app/oracle/fast_recovery_area

确认磁盘可用空间大于目标容量。

4.2 扩容

alter system set db_recovery_file_dest_size = 300g scope=both;

4.3 验证扩容结果

show parameter db_recovery_file_dest_size;

select name, round(space_limit / 1024 / 1024 / 1024, 2) as total_gb, round(space_used / 1024 / 1024 / 1024, 2) as used_gb, round((space_used / space_limit) * 100, 2) as pct_used from v$recovery_file_dest;

扩容后结果：

指标	扩容前	扩容后
总空间	20 gb	300 gb
使用率	99.65%	6.67%
可用空间	0.07 gb	约 280 gb

第五阶段：配置自动清理策略

在 rman 中配置归档日志自动删除：

rman target /

-- 配置归档日志删除策略：备库应用后自动删除
configure archivelog deletion policy to applied on standby;

预防措施总结

预防措施	配置方法	效果
扩容闪回恢复区	`alter system set db_recovery_file_dest_size = 300g`	从根本上解决空间不足问题
自动清理已应用日志	`configure archivelog deletion policy to applied on standby`	日志应用后自动删除，避免累积
定期空间监控	监控 `v$recovery_file_dest` 使用率	提前预警，避免被动
设置闪回保留时间	`alter system set db_flashback_retention_target = 720`	控制闪回日志保留时长

监控建议

建议建立自动化监控，每周执行以下 sql：

select 
    name,
    round(space_limit / 1024 / 1024 / 1024, 2) as total_gb,
    round(space_used / 1024 / 1024 / 1024, 2) as used_gb,
    round((space_used / space_limit) * 100, 2) as pct_used
from v$recovery_file_dest;

当 pct_used > 80% 时触发告警，提前介入处理，避免再次发生归档日志空间写满导致同步中断的问题。

总结

归档日志空间满导致 data guard 同步中断，是 dba 运维中常见的问题。本例中，通过清理历史日志快速恢复业务，再通过扩容和配置自动清理策略彻底解决问题。

核心经验：

及时监控：闪回恢复区使用率应纳入日常巡检
合理规划：初始配置应考虑业务增长，避免反复调整
自动运维：配置 rman 自动删除策略，减少手工干预

希望这篇文章能帮助遇到同样问题的 dba 同行快速定位和解决问题。

相关命令速查：

操作	命令
查看 fra 使用率	`select ... from v$recovery_file_dest;`
查看 gap	`select * from v$archive_gap;`
重启 mrp	`alter database recover managed standby database using current logfile disconnect;`
扩容 fra	`alter system set db_recovery_file_dest_size = 300g scope=both;`
配置自动删除	`configure archivelog deletion policy to applied on standby;`