rman恢复只读表空间必须先解冻状态再标准恢复：因scn冻结，需先alter tablespace read write解冻文件头，再执行restore+recover database until scn，最后open resetlogs；直接recover tablespace会跳过冻结校验导致ora-01122。
RMAN恢复只读表空间不能直接用recover tablespace跳过介质恢复步骤——因为只读表空间在备份时被冻结SCN，恢复时必须严格匹配该SCN，否则open报ORA-01122/ORA-01110。
只读表空间恢复前必须确认的三个状态
恢复失败大多源于状态不一致，不是命令写错，而是前提没对齐：
- 原表空间在备份时刻确实是
READ ONLY状态（查dba_tablespaces.status） - 损坏发生时表空间仍是
READ ONLY（若被误ALTER TABLESPACE ... READ WRITE过，就按读写表空间流程走） - 控制文件里该数据文件的
checkpoint_change#与备份时记录的SCN一致（用SELECT checkpoint_change# FROM v$datafile_header WHERE file# = X比对）
restore后必须用recover database until scn，不能recover tablespace
recover tablespace命令会忽略只读表空间的SCN冻结特性，强行应用归档日志，导致数据文件头SCN被改写，后续alter database open必然失败。正确做法是：
- 先
restore tablespace TBS_NAME（RMAN自动选最接近的只读备份片） - 再执行
recover database until scn <scn_from_backup></scn_from_backup>，SCN值从list backup of tablespace TBS_NAME输出中提取Ckp SCN列 - 最后
alter database open resetlogs——注意：此处resetlogs不可省，因只读表空间恢复属于不完全恢复范畴
归档日志路径和格式必须与原库完全一致
只读表空间恢复卡在recover阶段，90%是因为归档日志找不到。RMAN不校验路径是否存在，只按log_archive_format拼路径：
- 检查原库
show parameter log_archive_format，比如%t_%s_%r.dbf，新机必须一模一样 -
log_archive_dest_1指向的目录必须提前mkdir -p并chown oracle:oinstall - 若原库用了ASM，新机用文件系统，则需在
restore前用set newname for datafile X to '/path/to/file.dbf'映射，但归档路径仍要模拟ASM结构（如+DATA/ORCL/ARCHIVELOG/→/u01/arch/orcl/）
skip readonly备份下如何恢复？根本不可行
如果备份策略用了configure skip readonly on，那RMAN备份集里压根没有该表空间的数据文件——list backup of tablespace TBS_NAME返回空，restore直接报RMAN-06023。此时唯一出路是：
- 找最近一次含该表空间的全库备份（哪怕已过期），或
- 用
backup as copy镜像副本（它不遵从skip readonly配置），或 - 放弃RMAN，改用
expdp导出+impdp导入（前提是表空间未物理损坏，仅逻辑错误）
真正麻烦的永远不是命令怎么敲，而是你手里的备份到底有没有那个SCN点的只读快照——这点在执行list backup前就得确认清楚。
