pdb内只读表空间独立控制，alter tablespace read only仅影响当前pdb，不波及cdb$root或其他pdb；操作须在目标pdb中执行，备份、插拔、统计信息收集等均适配pdb边界，但需注意版本兼容性与默认表空间限制。
只读表空间在PDB内独立控制，无需跨容器干预
多租户架构下，每个PDB是逻辑隔离的数据库单元，ALTER TABLESPACE ... READ ONLY 命令只作用于当前PDB内的表空间，不会影响CDB$ROOT或其他PDB。这意味着你可以对某个租户（PDB）的数据归档表空间设为只读，而其他租户照常写入——不用像非CDB那样全局锁定或协调多个应用系统。
常见错误现象：在CDB$ROOT中执行 ALTER TABLESPACE users READ ONLY 会报错 ORA-65040，因为CDB根容器不允许直接操作用户表空间；必须先 ALTER SESSION SET CONTAINER=pdb_name 再操作。
- 操作前务必确认当前容器：
SHOW CON_NAME - PDB内创建的只读表空间，其数据文件路径、自动扩展策略、段空间管理方式均与CDB无关
- 备份恢复时，RMAN可单独针对某PDB执行
BACKUP PLUGGABLE DATABASE pdb_name，跳过只读表空间（需显式指定SKIP READONLY）
只读状态不阻断PDB级元数据变更
在非CDB中，表空间设为READ ONLY后，DROP TABLE 仍可成功（仅删字典），但 ANALYZE TABLE 或 TRUNCATE 会明确报 ORA-01642；而在PDB中，这类限制行为更可控——因为元数据操作（如统计信息收集）默认发生在SYSAUX表空间（属于PDB私有），只要SYSAUX可写，DBMS_STATS.GATHER_TABLE_STATS 就不会因目标表在只读表空间而失败。
性能影响小：只读表空间禁止的是数据块和段头更新，但PDB内SYS/SYSAUX的写入不受影响，监控工具（如AWR）看到的“log file sync”事件基本来自这些内部字典写，而非误判目标表空间被修改。
-
DBMS_STATS默认使用statown => 'SYS'，所以即使表在只读表空间，统计信息仍能写入PDB自己的SYSAUX - 若手动指定
statown指向只读表空间内的用户，则会失败，这是少数需要人工校验的点 -
EXPDP导出只读表空间中的表时，不会触发任何数据文件写，但会读取PDB本地的DBA_SEGMENTS等视图——这些视图元数据缓存在SGA中，开销极低
只读表空间的生命周期天然绑定PDB生命周期
一个只读表空间随PDB插拔而整体迁移，不需要额外导出/导入数据文件。例如将生产PDB热插拔到灾备CDB时，其中的只读表空间（如历史归档TS）自动带入，且状态保持不变；而传统非CDB若要迁移只读表空间，需手工拷贝数据文件+重建控制文件+校验SCN一致性，稍有不慎就会导致 v$datafile_header.last_change# 不一致，引发启动失败。
容易踩的坑：PDB unplugged 后再 plug into 另一个CDB，如果目标CDB版本低于源CDB（如21c → 19c），只读表空间可能因兼容性检查失败而无法open，此时必须先在源端用 ALTER TABLESPACE ... READ WRITE 临时切回读写态，再执行 downgrade 流程。
- 插拔前可用
SELECT file#, name, status FROM v$datafile WHERE con_id = SYS_CONTEXT('USERENV', 'CON_ID')快速确认当前PDB所有数据文件状态 - 只读表空间不能作为PDB的默认表空间（
DEFAULT TABLESPACE），否则创建用户会失败；但可以作为用户的TEMPORARY TABLESPACE或UNDO TABLESPACE——不过后者实际不会生效，因为UNDO必须在读写表空间中
