RMAN没有排除只读表空间的一键开关，仅通过SKIP READONLY（临时跳过当前只读表空间）或CONFIGURE EXCLUDE FOR TABLESPACE（永久剔除指定表空间）实现，二者互斥且误用会导致备份遗漏或恢复失败。
直接结论：RMAN 没有 “排除只读表空间” 的一键开关
rman 不会自动识别“只读”这个属性然后决定是否排除——它只认状态（read only）和命令显式控制。所谓“排除只读表空间”，本质是两种互斥路径：skip readonly（临时跳过所有当前只读的表空间），或 configure exclude for tablespace（永久剔除指定表空间，不管它是不是只读）。选错方式，要么没跳过，要么恢复时直接丢数据。
用 SKIP READONLY 跳过所有当前只读表空间
这是最轻量、最安全的临时方案，适合定期全备中规避长期不变的归档表空间（如 HIST_RO）。
-
SKIP READONLY必须写在BACKUP DATABASE命令末尾，不能嵌套在run{}块里，也不能跟EXCLUDE TABLESPACE混用 - 它只检查备份开始那一刻的
dba_tablespaces.status，如果表空间刚切为READ ONLY但事务未提交完，v$tablespace.status还是READ WRITE，就会漏跳 - 日志里出现
skipping datafile ... because it is read-only仅表示 RMAN 检测到该文件只读，不等于它被SKIP READONLY处理了——真正生效要靠查v$backup_datafile - 验证是否生效：执行
SELECT file#, tablespace_name FROM v$backup_datafile JOIN dba_data_files USING(file#) WHERE bs_key = (SELECT MAX(bs_key) FROM v$backup_set WHERE start_time > SYSDATE - 1);，若目标只读表空间的file#不在结果里，才算跳过成功
用 CONFIGURE EXCLUDE FOR TABLESPACE 永久剔除指定表空间
这不看状态，只看名字。一旦配置，所有后续 BACKUP DATABASE 都彻底无视该表空间，哪怕它后来被设为 READ WRITE 也照样排除。
- 表空间名严格区分大小写；如果创建时用了双引号（如
"Hist_TBS"），EXCLUDE里也必须带引号，否则配置无效 - 绝对不能对
SYSTEM、SYSAUX、UNDO、TEMP执行CONFIGURE EXCLUDE，否则BACKUP DATABASE直接报错退出 -
LIST BACKUP OF DATABASE输出里完全看不到被 exclude 表空间的数据文件，连条目都不生成 - 清除配置只能用
CONFIGURE EXCLUDE FOR TABLESPACE users CLEAR，UNCHECK或REMOVE是无效命令 - 误 exclude 关键业务表空间（如
APP_DATA）后，恢复数据库能打开，但应用一查表就报ORA-00942: table or view does not exist
最容易被忽略的边界情况
备份窗口内表空间状态可能动态变化——比如你凌晨 2 点启动 BACKUP DATABASE SKIP READONLY，但 2:05 有人执行了 ALTER TABLESPACE hist_ro READ WRITE，那这个表空间在本次备份中就不会被跳过，且不会报错、不会警告。RMAN 只在命令解析阶段快照一次状态，之后不再轮询。所以对关键只读表空间，建议配合 BACKUP TABLESPACE hist_ro 单独做校验备份，别只依赖 SKIP READONLY 的“自动性”。
