RMAN默认跳过只读表空间备份，因其通过比对数据文件头SCN（checkpoint_change#与last_change#相等）判定无变更；需用BACKUP FORCE DATABASE或单独BACKUP TABLESPACE强制备份以满足容灾恢复要求。

为什么 RMAN 默认会跳过只读表空间备份

rman 在执行 backup database 时，若检测到表空间为 read only 状态，且该表空间自上次备份后未发生数据文件头 scn 变化，就会自动跳过——这不是 bug，而是 rman 的默认优化行为。它依赖于控制文件中记录的 checkpoint_change# 和 last_change# 字段比对，只要两者相等，就认为“无变更”，不备份。

• 常见错误现象：RMAN-06900: WARNING: unable to generate a unique filename for archive log 不相关；真正容易被误判的是备份报告里压根没出现只读表空间的数据文件
• 使用场景：跨数据中心容灾、归档保留策略要求所有数据文件（含只读）必须有可恢复副本时，这个“跳过”就是隐患
• 性能影响：跳过确实减少 I/O 和备份窗口，但代价是丢失对该表空间某次异常（如文件损坏、误删）的独立恢复能力

强制备份只读表空间的两种可靠方式

不能靠改表空间状态或反复 ALTER TABLESPACE ... READ WRITE 再切回，那会引发日志切换和不必要的检查点。正确做法只有两个：

• 在 BACKUP DATABASE 命令中显式添加 INCLUDE CURRENT CONTROLFILE 并配合 PLUS ARCHIVELOG，但更关键的是加 FORCE 参数：BACKUP FORCE DATABASE —— 这会让 RMAN 忽略 SCN 比对，强制备份所有数据文件
• 单独备份只读表空间：BACKUP TABLESPACE users_readonly（假设表空间名为 users_readonly），这种方式最干净，不干扰主备份逻辑，也便于单独校验和恢复测试
• 注意：FORCE 不影响归档日志备份逻辑，也不改变备份集元数据中的 STATUS，但会增加备份大小和时间，需评估存储成本

检查只读表空间是否真被跳过：别只信 RMAN 输出日志

RMAN 日志里写 “skipping datafile … because it is read-only” 很常见，但这只是表面；真正要确认是否进备份集，得查控制文件视图或备份片内容。

• 查当前数据库中只读表空间列表：SELECT tablespace_name, status FROM dba_tablespaces WHERE status = 'READ ONLY'
• 查最近一次全备中是否包含这些表空间：SELECT bs_key, piece_name, completion_time FROM v$backup_piece bp JOIN v$backup_set bs ON bp.set_stamp = bs.set_stamp AND bp.set_count = bs.set_count WHERE bs_key IN (SELECT bs_key FROM v$backup_datafile WHERE file# IN (SELECT file_id FROM dba_data_files WHERE tablespace_name IN ('USERS_READONLY')))
• 容易踩的坑：用 LIST BACKUP OF DATABASE 查看时，输出只列 backup set，不展开 datafile 映射，容易误判；必须查 v$backup_datafile 或用 VALIDATE BACKUPSET 手动验证具体文件

RMAN 配置项 CONFIGURE EXCLUDE FOR TABLESPACE 和只读无关

这个配置常被误解为“跳过只读表空间”的开关，其实它只作用于 BACKUP DATABASE 中的 *命名排除*，和只读/读写状态完全无关。哪怕你 CONFIGURE EXCLUDE FOR TABLESPACE users_readonly，再执行 BACKUP DATABASE，它仍会跳过该表空间——但原因不是因为你 exclude 了，而是因为它只读 + 无变更。

• 真实效果：EXCLUDE 是硬性过滤，即使表空间是 READ WRITE 且刚插入数据，也会被跳过；而只读跳过是动态判断，一旦你执行 ALTER TABLESPACE ... READ WRITE 再 ALTER ... READ ONLY，SCN 更新，下次备份就会包含它
• 兼容性注意：12c 及以后版本中，EXCLUDE 对 BACKUP PLUGGABLE DATABASE 也生效，但依然不影响只读逻辑判断
• 建议：如果真想长期排除某个只读表空间，优先用单独备份 + 清单管理，而不是依赖 EXCLUDE，否则恢复流程会断裂

事情说清了就结束。只读表空间的“跳过”本质是 RMAN 对静态数据的懒加载策略，不是缺陷也不是配置错误；但一旦你的恢复 RPO 要求覆盖所有文件，就必须主动打破这个懒加载——靠 FORCE 或显式 BACKUP TABLESPACE，别指望控制文件自动帮你记住“这个只读表空间很重要”。