rman默认不跳过只读表空间，必须显式指定skip readonly才能减少备份量；否则即使表空间为read only，backup database仍会包含其数据文件，导致备份体积、i/o和时间无节省。
RMAN 默认不跳过只读表空间，必须显式启用 SKIP READONLY 才能真正减少备份量
为什么 BACKUP DATABASE 不自动跳过只读表空间
很多人误以为 RMAN 会默认忽略只读表空间，其实不会——BACKUP DATABASE 命令在 Oracle 19c 中仍会包含所有在线的、状态为 READ ONLY 的表空间，除非你明确加了 SKIP READONLY。不加这个参数，备份集体积不会变小，I/O 和时间也不会节省。
常见错误现象是：明明把历史分区表空间设为只读，但全备耗时和大小跟之前几乎一样，LIST BACKUP OF TABLESPACE xxx 却显示它被备份了。
-
CONFIGURE BACKUP OPTIMIZATION ON不影响只读表空间是否参与本次备份，它只决定“是否复用已有备份”，对首次备份无效 - 只读表空间的数据文件头部 SCN 被冻结，RMAN 无法靠“无变化”自动跳过，必须靠策略指令
- 若用了恢复目录（recovery catalog），记得执行
RESYNC CATALOG，否则 RMAN 可能缓存旧的只读状态，导致SKIP READONLY行为异常
如何正确启用 SKIP READONLY 并验证效果
直接在备份命令中追加 SKIP READONLY 是最可靠的方式，比依赖配置项更直观可控。
实操建议：
- 执行全备时写成：
BACKUP DATABASE SKIP READONLY PLUS ARCHIVELOG; - 若需压缩，加上
AS COMPRESSED BACKUPSET，例如：BACKUP AS COMPRESSED BACKUPSET DATABASE SKIP READONLY FORMAT '/u01/rman/%U.bak'; - 验证是否生效：备份后运行
LIST BACKUP OF TABLESPACE users;（把users换成你的只读表空间名），若返回RMAN-06004: ORACLE error from recovery catalog database或空结果，说明确实跳过了 - 对比备份集大小：用
LIST BACKUP SUMMARY;查看各备份集的SIZE列，跳过前后应有明显差异（尤其当只读表空间占总数据量较大时）
备份优化的两个隐藏前提不能漏
即使加了 SKIP READONLY，若以下任一条件不满足，备份仍可能失败或不按预期跳过：
- 只读表空间的所有数据文件必须是
AVAILABLE状态，查：SELECT file_name, status FROM dba_data_files WHERE tablespace_name = 'YOUR_TS';—— 若出现INVALID或RECOVER，RMAN 会报RMAN-03009并中断 - 表空间不能处于
OFFLINE或READ WRITE状态；哪怕只是临时被ALTER TABLESPACE ... READ WRITE过一次，再切回只读，RMAN 也会重新将其视为“可能变更”，除非再次显式跳过 - 如果用了
BACKUP AS COPY（镜像副本），SKIP READONLY不生效——镜像副本本质是 OS 级拷贝，不走 RMAN 备份逻辑，需单独管理
别把 SKIP READONLY 和 EXCLUDE 混用
EXCLUDE 是静态排除，SKIP READONLY 是动态策略。两者机制完全不同，混用反而容易出问题。
比如这样写是错的：
RUN {
BACKUP DATABASE EXCLUDE TABLESPACE users SKIP READONLY;
}
RMAN 会忽略 SKIP READONLY，只执行 EXCLUDE，而且后续恢复时若依赖该表空间，就彻底没得救。
- 优先用
SKIP READONLY：它随表空间状态自动适配，今天只读就跳，明天改读写就自动包含 - 慎用
EXCLUDE：仅适用于长期确定不需备份的表空间（如临时测试库），且必须确保恢复时可重建或不依赖 - 绝对不要在生产备份脚本里写死
EXCLUDE TABLESPACE，一旦 DBA 忘记同步更新，恢复链就断了
真正省空间的关键，不是少备份几个文件，而是让 RMAN 理解“这部分数据永远不会变”，然后靠 SKIP READONLY 把判断权交还给它的状态机——而不是靠人去维护一份易过期的排除列表。
