Oracle 19c默认不备份只读表空间，因其设计为跳过以减少冗余和I/O；须用INCLUDE CURRENT CONTROLFILE或显式BACKUP TABLESPACE命令覆盖该行为，否则恢复失败。
Oracle 19c 默认不备份只读表空间，除非显式指定或启用相关选项——这是恢复失败最常见的原因。
为什么 RMAN 默认跳过只读表空间
RMAN 在执行 BACKUP DATABASE 时，会自动忽略状态为 READ ONLY 的表空间。这不是 bug，而是设计行为：避免冗余备份、减少 I/O 开销。但一旦该表空间被误删或数据文件损坏，且你没单独备份过它，就无法直接恢复。
- 检查只读表空间：运行
SELECT tablespace_name, status FROM dba_tablespaces WHERE status = 'READ ONLY'; - 验证备份是否包含它：在 RMAN 中执行
LIST BACKUP OF TABLESPACE users;（把users换成你的只读表空间名），若返回空或报错RMAN-06004，说明没备份上 - 根本原因常是：备份命令没加
INCLUDE CURRENT CONTROLFILE或没显式列出该表空间
正确备份只读表空间的两种方式
必须打破“默认跳过”逻辑，用明确指令覆盖行为。
- 方式一：在全库备份中强制包含（推荐用于常规策略）
使用BACKUP DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG;
注意：INCLUDE CURRENT CONTROLFILE是关键，它触发 RMAN 扫描并包含所有表空间，无论读写状态 - 方式二：单独备份只读表空间（精准可控）
先确认 PDB 上下文（如适用）：ALTER SESSION SET CONTAINER = pdb1;
再执行：BACKUP TABLESPACE pdb1:readonly_ts;（CDB$ROOT 下执行，带 PDB 限定符）
或普通 CDB 表空间：BACKUP TABLESPACE readonly_ts; - 额外建议：对只读表空间启用
BACKUP AS COPY，生成镜像副本，恢复时可直接SWITCH，比从备份集还原快得多
恢复只读表空间时的关键限制
只读表空间恢复后，不能直接 ALTER TABLESPACE ... READ WRITE —— 它仍需保持只读，否则可能破坏一致性。
- 恢复流程与读写表空间基本一致：
RESTORE TABLESPACE readonly_ts;→RECOVER TABLESPACE readonly_ts;→ALTER TABLESPACE readonly_ts ONLINE; - 但注意：
RECOVER步骤实际不应用归档日志（因为只读期间无变更），RMAN 会快速跳过；若报RMAN-06026（some targets not found），通常只是提示，不影响结果 - 若表空间在备份时刻是只读，但恢复目标时间点之后被设为读写，RMAN 会拒绝恢复——必须确保恢复时间点 ≤ 表空间最后一次
READ ONLY切换时间 - 验证恢复后状态：
SELECT tablespace_name, status, plugged_in FROM dba_tablespaces WHERE tablespace_name = 'READONLY_TS';，确认status为READ ONLY且plugged_in为YES
容易被忽略的兼容性细节
只读表空间的备份/恢复行为在 CDB/PDB 架构下有隐含依赖，不是单纯语法问题。
- 如果只读表空间属于某个 PDB，而你在该 PDB 内连接 RMAN 并执行
BACKUP TABLESPACE readonly_ts，RMAN 会报ORA-65023或静默失败——必须回到CDB$ROOT执行，且用pdb_name:tablespace_name格式 - 使用恢复目录（Recovery Catalog）时，只读表空间的元数据可能延迟同步；首次备份后，建议立即执行
RESYNC CATALOG; - Windows 路径中的反斜杠
\在FORMAT字符串里需转义或改用正斜杠，否则BACKUP ... FORMAT 'D:\backup\%U'可能被解析为控制字符，导致备份路径错误
