【RAC控制文件备份失败】ORA-00245 踩坑全记录

环境说明：本文基于 Oracle 11g R2（11.2.0.3.0）Enterprise Edition，2 节点 RAC，节点名 rac1 / rac2。

引言：凌晨的告警，沉默的隐患

凌晨零点刚过，某生产 RAC 的监控系统悄无声息地抛出一条告警——

ORA-00245: control file backup failed; target is likely on a local file system

没有业务中断，没有用户投诉，数据库照常运行。看起来人畜无害，对吧？

错。

控制文件备份静默失败，意味着你的 RMAN 备份集里缺失了最关键的那一份。一旦遭遇存储故障，捧着残缺的备份集面对老板，那才叫真正的"凌晨事故"。

这篇文章，就来把这个"温水煮青蛙"式的隐患彻底说清楚。

一、故障现象

时间：2026-06-01 00:10:06

rac2 节点 alert 日志：

Mon Jun 01 00:10:06 2026
Control file backup creation failed.
Backup target file size found to be zero.
Errors in file .../trace/rac2_arc0_19741.trc:
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

rac1 节点 alert 日志：

Mon Jun 01 00:10:06 2026
Errors in file .../trace/rac1_ora_24779.trc:
ORA-00245: control file backup failed; target is likely on a local file system

两个节点，两种口味的报错：

• rac1：直接告诉你"目标路径像是本地文件系统"
• rac2：文件找到了，但 size 为 0，同样备份失败

去检查文件，真相一目了然：

# rac1 节点——文件根本不存在
[oracle@rac1 dbs]$ ll /u01/oracle/11.2.0.3/product/dbs/snapcf_rac1.f
ls: 无法访问 snapcf_rac1.f: 没有那个文件或目录

# rac2 节点——文件存在，但 arc0 读到 size=0
[oracle@rac2 dbs]$ ll /u01/oracle/11.2.0.3/product/dbs/snapcf_rac2.f
-rw-r----- 1 oracle asmadmin 77971456 2月  1 15:49 snapcf_rac2.f

二、快照控制文件（Snapshot Controlfile）是什么？

在深入根因之前，先补一堂原理课。

Oracle RMAN 在备份控制文件时，不能直接读取正在被数据库使用的 current controlfile（会有并发写入风险）。因此 RMAN 会先把控制文件快照到一个临时副本，再对这个副本进行备份。这个临时副本，就是 Snapshot Controlfile（快照控制文件），简称 snapcf。

其路径由如下 RMAN 参数控制：

RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
-- 单机默认：$ORACLE_HOME/dbs/snapcf_<sid>.f

单机环境下，这个默认路径完全没问题——只有一个节点，本地路径随便用。

但在 RAC 环境下，问题来了。

三、根因分析：两个致命误配

问题一：snapcf 配置在节点本地路径

查看故障环境的 RMAN 配置：

-- rac1 节点的配置
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/oracle/11.2.0.3/product/dbs/snapcf_rac1.f';

-- rac2 节点的配置
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/oracle/11.2.0.3/product/dbs/snapcf_rac2.f';

乍一看，两个节点各配各的，似乎"对称、整齐"——然而这正是问题所在。

RAC 的核心机制决定了：RMAN 备份任务可能在任意节点上执行。

当 RMAN 任务在 rac1 上触发，它去写 snapcf_rac1.f（rac1 本地路径）没问题；但 RMAN 要求备份期间所有节点都能访问同一份 snapcf，rac2 无法跨节点读取 rac1 的本地磁盘，于是：

• rac1 备份时，rac2 上的 snapcf_rac1.f 压根不存在 → No such file or directory
• rac2 即便本地有 snapcf_rac2.f，但 arc0 在尝试写入/核验时拿到的 size = 0，同样失败

本质原因：/u01/oracle/...dbs/ 是节点本地文件系统，不是共享存储，RAC 各节点之间互不可见。

Oracle 官方文档明确要求：

In a RAC environment, the snapshot control file must reside on shared storage accessible by all nodes (ASM, NFS, or cluster file system).

问题二：autobackup format 路径硬编码了过期日期

再看另一处配置：

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
  TO '/u01/backup/autobackup/2024-07-29/%F';

注意到了吗？路径里写死了 2024-07-29。

这意味着自 2024 年 7 月 29 日之后，备份文件都尝试写入一个早已"过期"的目录——那个目录极有可能已被清理或根本从未创建过。备份系统在"自欺欺人"地工作着，而 DBA 浑然不觉。

两个配置错误叠加，让控制文件备份在相当长的时间里一直处于静默失败状态。

四、修复步骤

Step 1：将 snapcf 迁移到共享存储

方案 A（推荐）：使用 ASM 磁盘组

-- 在任意节点以 RMAN 连接 target 执行一次，RAC 全局生效
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/snapcf_rac.f';
-- 将 +DATA 替换为你环境中实际的 ASM 磁盘组名

方案 B：使用 NFS 或集群共享文件系统路径

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/nfs/orashared/snapcf_rac.f';
-- 确保该 NFS 路径在所有节点均已挂载且 oracle 用户有读写权限

注意：在 RAC 中，CONFIGURE 命令只需在一个节点执行，配置会写入控制文件，自动对所有实例生效。无需在每个节点重复执行。

Step 2：修复 autobackup format，去掉硬编码日期

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
      TO '/u01/backup/autobackup/%F';
-- %F 是 RMAN 自动生成的唯一文件名（含时间戳），无需手动维护日期目录

同时确认目标目录存在且可写：

mkdir -p /u01/backup/autobackup
chown oracle:oinstall /u01/backup/autobackup

Step 3：验证修复结果

-- 确认配置已更新
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
RMAN> SHOW CONTROLFILE AUTOBACKUP FORMAT;

-- 手动触发一次备份，验证不再报错
RMAN> BACKUP CURRENT CONTROLFILE;

-- 检查备份集是否正常生成
RMAN> LIST BACKUP OF CONTROLFILE;

若输出中出现 BS Key、Piece Name 等信息且无报错，说明修复成功。

五、延伸踩坑点

RAC 环境下 RMAN 配置有几处容易踩坑，趁此机会一并整理：

另一个高频误区：有些 DBA 在 RAC 两个节点分别执行 CONFIGURE，以为"两边都配了更保险"。实则两次配置会相互覆盖，最终生效的是最后一次执行的节点配置——如果最后一次又配了本地路径，等于白修。

六、总结

这次 ORA-00245 故障，用一句话概括：

把单机思维带进了 RAC 环境，snapcf 配到了本地磁盘，跨节点访问失败，控制文件备份静默失效。

核心修复动作只有两步：

1. snapcf 路径 → 共享存储（ASM 磁盘组或 NFS）
2. autobackup format → 去掉硬编码日期目录

更重要的是，这次故障提醒我们：备份失败不等于数据库报错。RMAN 的静默失败可以在 alert 日志里悄悄躺着好几个月，直到真正需要恢复的那一刻才暴露。

建议将以下检查加入日常运维巡检项：

# 每日检查 alert 日志中是否存在 ORA-00245 / backup failed 关键词
grep -i "backup failed\|ORA-00245\|ORA-27037" $ORACLE_BASE/diag/rdbms/*/trace/alert_*.log

备份是 DBA 的最后一道防线，请认真对待每一条告警。

专注于 Oracle / MySQL / PostgreSQL / 达梦等主流数据库的运维实战与架构分享，欢迎关注，一起做靠谱的数据库人。