RMAN默认不自动跳过只读表空间，必须显式使用SKIP READONLY、CONFIGURE EXCLUDE FOR TABLESPACE或启用BACKUP OPTIMIZATION并满足前提条件才能跳过；否则所有ONLINE状态的只读表空间均被纳入BACKUP DATABASE。
rman 不会“自动跳过”只读表空间——除非你明确告诉它跳过，否则它默认照常备份所有在线的只读表空间。
BACKUP DATABASE 默认包含 READ ONLY 表空间
RMAN 的 BACKUP DATABASE 命令默认把所有 STATUS = 'ONLINE' 的数据文件都纳入备份范围，不管它是 READ WRITE 还是 READ ONLY。所谓“自动跳过”，其实是误读日志或混淆了不同机制。
- 常见错觉来源：RMAN 日志里出现
skipping datafile 5; because it is read-only，但这只是说明 RMAN 检测到该文件只读，并不表示它被跳过了——真正是否进备份集，得查v$backup_datafile - 真实行为：只要没加
SKIP READONLY、没配CONFIGURE EXCLUDE FOR TABLESPACE、也没开BACKUP OPTIMIZATION ON并满足其前提，RMAN 就会备份该只读表空间 - 验证方法：执行
LIST BACKUP OF DATABASE;后，再用SELECT file#, tablespace_name FROM v$backup_datafile WHERE bs_key = (SELECT MAX(bs_key) FROM v$backup_set);查实际备份了哪些文件
真正能导致“跳过”的三种显式机制
只有以下三者之一生效，RMAN 才可能不备份某个只读表空间：
-
BACKUP DATABASE SKIP READONLY：命令级临时跳过，仅对当前备份生效；必须写在主命令末尾，不能嵌套在run{}里 -
CONFIGURE EXCLUDE FOR TABLESPACE 'TS_NAME';：配置级永久排除，后续所有BACKUP DATABASE都无视该表空间（哪怕它后来改成READ WRITE） -
CONFIGURE BACKUP OPTIMIZATION ON;+ 已有该只读数据文件的有效备份：RMAN 比对控制文件中记录的checkpoint_change#，若未变且已有备份，则标记为 “already backed up” 并跳过——但前提是首次备份已执行过
为什么有人觉得“自动跳过”？常见误判点
很多 DBA 看到备份时间缩短、日志里有 skipping 提示，就以为 RMAN 自动优化了，其实背后往往是状态或配置没对齐：
- 表空间实际不是
READ ONLY：比如刚执行ALTER TABLESPACE tbs READ ONLY，但事务未提交，dba_tablespaces.status仍是READ WRITE - 用了
BACKUP AS COPY：该模式下BACKUP OPTIMIZATION完全不生效，只读表空间照样全量拷贝 - 控制文件损坏或未启用
AUTOBACKUP：RMAN 无法读取冻结 SCN，BACKUP OPTIMIZATION判定失败，退回到全量备份 - 误把
SKIP OFFLINE或SKIP INACCESSIBLE当成跳过只读——这两者跟只读状态无关，只处理离线/损坏文件
跳过之后还能恢复吗？关键依赖在哪
能恢复，但有个硬前提：控制文件必须被正确备份。
- RMAN 在
RESTORE DATABASE时，靠控制文件里记录的表空间状态（READ ONLY）决定是否还原对应数据文件；如果控制文件没备份，或者备份太旧（早于表空间设为只读的时间点），RMAN 会尝试还原缺失文件，报ORA-19573: cannot obtain exclusive enqueue of datafile类错误 - 推荐做法：每次
BACKUP DATABASE都加上INCLUDE CURRENT CONTROLFILE，或单独执行BACKUP CURRENT CONTROLFILE - 注意：如果只读表空间后来被切回
READ WRITE，下一次备份必须去掉SKIP READONLY，否则新写入的数据将丢失
最易被忽略的是：RMAN 对只读表空间的处理完全依赖控制文件中冻结 SCN 的一致性，而不是文件系统时间戳或归档日志位置。一旦人为修改过数据文件头（比如用 dd 覆盖），哪怕表空间仍是 READ ONLY，RMAN 也可能因校验失败拒绝跳过，直接报 ORA-19602。
