可以设置表空间为只读，但必须确保其处于ONLINE状态、未在备份中、非SYSTEM/UNDO/临时表空间，且无未提交事务；成功后仅禁止DML写入数据块，不限制DDL操作。
直接结论：可以设置，但必须满足几个硬性前提，否则会报错 ora-01123 或 ora-00372。
执行 ALTER TABLESPACE ... READ ONLY 前必须确认的条件
这条语句不是“一发即中”的操作，Oracle 会在执行时做实时校验。常见失败原因包括：
- 表空间处于
OFFLINE状态 —— 必须是ONLINE； - 表空间正在被
BACKUP（比如用了ALTER TABLESPACE ... BEGIN BACKUP）—— 必须先END BACKUP； - 目标是
SYSTEM、UNDO或当前活动的临时表空间 —— 这些禁止设为只读； - 有未提交的事务正在修改该表空间中的对象 —— Oracle 会等待所有事务结束才真正切换状态，期间语句阻塞，但不会报错。
ALTER TABLESPACE ... READ ONLY 的实际行为表现
执行成功后，并非立刻“冻结”所有写入，而是进入一种“事务级只读”状态：
- 新发起的
INSERT/UPDATE/DELETE会立即报ORA-00372； - 已存在的 DML 事务若尚未提交，仍可继续，直到
COMMIT或ROLLBACK； -
DROP TABLE、DROP INDEX等 DDL 仍允许 —— 因为它们只改数据字典，不写数据文件； - 不会阻止
ALTER TABLE ... ADD COLUMN或MODIFY（只要没触发物理重写），但不能新增段（如不能INSERT导致扩展）。
为什么建议在设只读前执行一次全表扫描？
这不是强制步骤，但会影响后续查询性能。原因在于：
- Oracle 在只读模式下跳过某些块级事务状态检查（比如是否需要应用 UNDO）；
- 但如果某数据块从未被访问过，首次读取时仍要验证其 SCN 和事务状态；
- 执行类似
SELECT COUNT(*) FROM tab_name可以“预热”所有块，把状态固化下来； - 尤其对大表或历史归档表，这步能显著减少后续 OLAP 查询的延迟抖动。
解除只读的注意事项
用 ALTER TABLESPACE ... READ WRITE 切回后，不会自动恢复写保护，但要注意：
- 如果表空间曾离线再上线过，需确认所有数据文件头一致，否则可能报
ORA-01122； - 切换瞬间不产生日志风暴，但之后第一次写入会触发隐式检查点；
- 如果之前用它做过传输表空间（TTS），记得导出元数据后，再切回读写 —— 否则
EXPDP会因状态不一致失败。
最容易被忽略的是：只读表空间仍然能被 DROP 对象，也能被 TRUNCATE（只要权限足够）。所谓“只读”，仅限制对数据块的修改，不约束数据字典变更。真要防误删，得靠权限控制或审计配合。
