开启 backup optimization 后仍备份只读表空间，因其默认不跳过只读表空间，仅对已修改的数据文件做去重判断；真正跳过需显式配置 exclude 或使用 skip readonly。
backup optimization 开启后为什么还是备份了只读表空间
因为 backup optimization on 默认不跳过只读表空间——它只对“未更改的数据文件”做去重判断，而只读表空间即使内容没变，rman 仍视其为“需显式处理”的对象。是否跳过，取决于你有没有配 configure exclude for tablespace 或在备份命令里加 skip readonly。
-
BACKUP OPTIMIZATION的核心逻辑是：对比上次备份时间戳 + 归档日志 SCN，判断数据文件是否真正被修改过；只读表空间的文件头 SCN 停滞，但它不参与该比较流程 - 只读表空间默认会被包含进
BACKUP DATABASE，除非你明确排除 - 如果同时开了
BACKUP OPTIMIZATION和EXCLUDE FOR TABLESPACE，后者优先级更高，但两者解决的是不同问题：一个是“要不要备份”，一个是“要不要重复备份”
如何让 RMAN 真正跳过只读表空间（两种可靠方式）
必须显式干预，不能依赖 BACKUP OPTIMIZATION 自动处理。最常用且互斥的两种方式：
- 全局配置排除：
CONFIGURE EXCLUDE FOR TABLESPACE 'USERS_RO' CLEAR;→ 改成CONFIGURE EXCLUDE FOR TABLESPACE 'USERS_RO';，之后所有BACKUP DATABASE都自动跳过该表空间（注意：BACKUP TABLESPACE显式指定时仍会执行） - 单次备份跳过：
BACKUP DATABASE SKIP READONLY;，这个命令会绕过所有当前状态为READ ONLY的表空间，无论是否配置了EXCLUDE - 混合使用要注意：如果某表空间既被
EXCLUDE又在SKIP READONLY场景下，不会报错，但行为以EXCLUDE为准（即彻底不纳入备份集）
SKIP READONLY 和 BACKUP OPTIMIZATION 同时启用有冲突吗
没有冲突，但作用域完全不同，容易误以为“叠加生效”。实际是分层过滤：
-
SKIP READONLY是第一道筛选，在构建备份目标列表时就剔除只读表空间，后续完全不进入 RMAN 备份决策流程 -
BACKUP OPTIMIZATION是第二道筛选，在已选定的、可写的表空间中，再比对变更状态决定是否跳过备份 - 所以同时写
BACKUP DATABASE SKIP READONLY BACKUPSET PLUS ARCHIVELOG;时，BACKUP OPTIMIZATION对只读表空间根本不起作用——它连看都看不到
验证是否真的跳过了只读表空间
别只看 RMAN 输出里的 “skipping” 字样，有些版本会把 SKIP READONLY 的提示藏在 debug 日志里。稳妥方法是查备份集内容：
- 运行
LIST BACKUP OF DATABASE;，记下备份集BS_KEY - 再运行
LIST BACKUPSET <code>BS_KEY;，观察输出中是否有你预期跳过的表空间名（如USERS_RO） - 更直接的方式：
SELECT * FROM V$BACKUP_DATAFILE WHERE FILE# IN (SELECT FILE# FROM DBA_DATA_FILES WHERE TABLESPACE_NAME = 'USERS_RO');—— 如果返回空，说明确实没备进去
最容易被忽略的是：表空间状态可能在备份窗口内动态切换。比如备份开始时是 READ WRITE，中途被 ALTER TABLESPACE ... READ ONLY，RMAN 不会中断或回滚，而是继续备份——跳过只读表空间只检查命令发起时刻的状态。
