不能，执行ALTER TABLESPACE ... BEGIN BACKUP会直接报错ORA-01642，因只读表空间数据文件头SCN已冻结、无脏块、无需热备机制；RMAN备份应启用BACKUP OPTIMIZATION以跳过未变更的只读文件。
只读表空间能用 alter tablespace ... begin backup 吗？
不能。执行会直接报错：ORA-01642: begin backup not needed for read only tablespace。因为只读表空间的数据文件头已被冻结，SCN 固定，DBWn 已完成强制检查点，所有脏块落盘，后续不再变更——热备机制（冻结头部 + 记录变化块）对它完全无意义。
常见误操作是照搬读写表空间的热备流程，在只读表空间上执行 begin backup，结果卡在报错，耽误备份窗口。
- 只读表空间不支持热备，RMAN 也不需要为它启动 backup set 的“热备模式”
- OS 层
cp或 RMANbackup as backupset tablespace xxx是合法且推荐的方式 - 若误执行了
begin backup，需先end backup才能继续其他操作，否则v$backup里状态会异常挂起
RMAN 备份只读表空间时要不要开 BACKUP OPTIMIZATION？
要开，而且建议全局启用：CONFIGURE BACKUP OPTIMIZATION ON。RMAN 会自动跳过内容未变的只读数据文件，避免重复备份——前提是该文件自上次备份后没被改回读写再改回来（即 SCN 未变）。
不开优化选项的话，RMAN 每次全库备份都会把只读表空间重新打一遍包，浪费磁盘、带宽和时间，尤其当它占几百 GB 时，影响明显。
- 只读表空间一旦置为 READ ONLY，其数据文件头的
checkpoint_change#就固定，RMAN 以此判断是否“已备份且未变更” - 如果中途执行过
alter tablespace ... read write再read only，SCN 重置，RMAN 会认为它“已变更”，下次仍会备份 -
LIST BACKUP OF TABLESPACE tbs_name可验证是否真被跳过
只读表空间损坏后，restore 和 recover 怎么选？
绝大多数情况只需 restore，不用 recover。因为只读表空间没有重做日志活动，不存在“应用归档日志”的必要性——它的 SCN 是静止的，恢复目标就是还原到那个冻结的 SCN 状态。
典型错误是看到 “database needs recovery” 就条件反射敲 recover database，结果报错：ORA-00283: recovery session canceled due to errors，因为 RMAN 找不到对应日志序列或发现该文件无需前滚。
- 文件丢失或损坏：直接
RESTORE DATAFILE n或RESTORE TABLESPACE tbs_name - 控制文件中该文件状态为 OFFLINE：恢复后需手动
ALTER TABLESPACE tbs_name ONLINE - 仅当该表空间曾被设为 READ WRITE 并产生过归档日志，之后又改回 READ ONLY —— 此时若用 READ WRITE 时期的备份恢复，则可能需要
RECOVER到切换为只读前的那个 SCN
重建控制文件时，只读数据文件路径怎么处理？
用 ALTER DATABASE BACKUP CONTROLFILE TO TRACE 生成的脚本里，只读数据文件默认不会出现在 CREATE CONTROLFILE 的 DATAFILE 子句中，而是以 ALTER DATABASE RENAME FILE 'MISSING00006' TO '...' 形式补在末尾。
如果不注意这点，直接运行 trace 脚本重建控制文件，数据库启动后会提示 ORA-01157: cannot identify/lock datafile，因为控制文件根本不知道这个只读文件的存在。
- 必须保留 trace 文件中所有
ALTER DATABASE RENAME FILE和ALTER TABLESPACE ... ONLINE的语句 - 若使用手工写的
CREATE CONTROLFILE，务必把只读数据文件的完整路径显式加入DATAFILE列表 - 验证方式：
SELECT file_name, status FROM dba_data_files WHERE tablespace_name = 'TBS_NAME'，status 应为ONLINE，而非RECOVER或空
ORA-01110 或 ORA-01578，排查起来容易绕远。动手前先确认 v$datafile 里的 enabled 和 status 列，比反复 restore 更省时间。 
