允许执行SELECT查询，只要用户具备对应表的SELECT权限；但FOR UPDATE会阻塞只读切换或报错，物化视图FAST刷新在只读表空间会因无法写日志而失败。
可以执行查询（SELECT），但必须避开 FOR UPDATE 和未提交事务干扰
READ ONLY 表空间下 SELECT 是否被允许
允许。只要用户有对应表的 SELECT 权限，就能正常执行 SELECT 查询，包括全表扫描、索引扫描、JOIN、子查询等常规操作。Oracle 不会在只读表空间上拦截纯读取语句。
但要注意：不是所有“看起来是读”的操作都真能跑通——关键看是否隐式申请锁或依赖一致性读快照的完整性。
哪些 SELECT 会失败或阻塞切换
-
SELECT ... FOR UPDATE会阻塞ALTER TABLESPACE ... READ ONLY切换，因为它持有行级锁，影响 SCN 快照生成；已在只读状态下执行该语句则直接报错ORA-01555: snapshot too old或ORA-00372: file cannot be modified - 查询涉及全局临时表（
GLOBAL TEMPORARY TABLE）本身不受限，但若其定义在只读表空间中（极少见），且当前会话有活跃临时段事务，仍可能卡住切换流程 - 使用物化视图刷新（
DBMS_MVIEW.REFRESH）时，若基表在只读表空间，且刷新方式为FAST，会因无法写日志表而失败
为什么有些 SELECT 看似成功却查不到最新数据
READ ONLY 表空间的数据文件头部 SCN 被冻结，后续所有查询都基于这个固定 SCN 构建一致性读（CR）块。这意味着：
— 如果你在切换前刚插入一行但没提交，那行数据不会出现在只读后的任何 SELECT 结果里（它从未真正落盘）
— 如果你切换后又在其他可写表空间更新了关联表，JOIN 查询结果可能“看起来不一致”，但这不是 bug，而是 Oracle 严格按 SCN 对齐的必然表现
— 没有自动机制去“预热”所有数据块；首次访问某块时仍需构造 CR 块，可能略慢，尤其当块变更频繁的历史 SCN 差距大时
容易被忽略的权限与对象边界
只读限制作用于**段（segment）所在表空间的物理写入**，不控制数据字典操作：
- 可以在只读表空间里的表上执行
ALTER TABLE ... ADD COLUMN（修改数据字典，不改数据文件） - 可以
DROP TABLE或DROP INDEX（删元数据，段空间标记为 reusable，但不擦除原块） - 不能
CREATE TABLE、INSERT、UPDATE、TRUNCATE—— 这些都需要分配/修改数据块 -
SELECT COUNT(*)是安全的暖机手段，但别用/*+ FULL */强制扫全量，除非你确认缓存和 I/O 能扛住
最常漏检的是：以为只读 = 安全导出，结果 expdp 报 ORA-39126: Worker unexpected fatal error —— 因为 Data Pump 需要 SYSAUX 和 SYSTEM 表空间可写来记录作业元数据，跟只读表空间本身无关。
