ORA-00372或ORA-01642报错应先查DBA_TABLESPACES中表空间STATUS是否为READ ONLY，若为READ ONLY且CONTENTS=PERMANENT，则应用DML被拒绝属正常行为；再检查数据文件STATUS和ENABLED状态，以及V$DATAFILE_HEADER中SCN一致性。
应用报 ORA-00372 或 ORA-01642 时先查表空间状态
这类错误不是权限或连接问题，而是 oracle 明确拒绝写入只读表空间。第一反应不该是改应用代码，而是确认 dba_tablespaces 中对应表空间的 status 是否为 read only：
SELECT tablespace_name, status, contents FROM dba_tablespaces WHERE tablespace_name = 'USERS';
如果返回 READ ONLY，且应用恰好在往该表空间里的表做 INSERT、UPDATE 或 DELETE，就对上了。注意 CONTENTS 列必须是 PERMANENT —— 若是 TEMPORARY 或 UNDO，根本不可能设成只读，报错会是 ORA-03217。
检查数据文件是否 offline 或 recover pending
只读表空间的数据文件如果处于 OFFLINE 或 RECOVER 状态，即使表空间本身是 READ ONLY，也会导致查询都失败（比如 ORA-01157）。别只盯表空间层级，得下钻到文件：
SELECT file_name, status, enabled FROM dba_data_files WHERE tablespace_name = 'USERS';
-
STATUS = 'AVAILABLE'是正常； -
STATUS = 'RECOVER'表示文件需要介质恢复，哪怕表空间只读也拦不住报错； -
ENABLED = 'DISABLED'说明文件被 offline，需先ALTER DATABASE DATAFILE ... ONLINE（但只读表空间不支持 online 操作，得先切回读写）。
为什么 SELECT 都报错？重点看 V$DATAFILE_HEADER
有些场景下，表空间明明是 READ ONLY，SELECT 却仍报 ORA-00372 或 ORA-01110。这时不是逻辑限制，而是底层数据文件头损坏或 SCN 不一致。查 V$DATAFILE_HEADER 能暴露真实问题：
SELECT file#, status, checkpoint_change#, last_change# FROM v$datafile_header WHERE name LIKE '%users%';
关键看两列：
-
LAST_CHANGE#非空 → 文件曾被设为只读，但之后又被写过（比如误操作切回读写又没归档）； -
CHECKPOINT_CHANGE# != LAST_CHANGE#→ 文件头与控制文件 SCN 不同步，必须恢复； - 若
STATUS = 'ONLINE'但LAST_CHANGE#为空，却仍报错，大概率是文件系统权限或磁盘不可读，和只读设置无关。
应用层绕不过去？临时方案要避开元数据写入
生产上不能立刻切回读写时，有些操作看似“只读”实则隐含写入，必须规避：
-
ANALYZE TABLE ... COMPUTE STATISTICS会更新SYSAUX里的字典表，但若目标表在只读表空间，可能因尝试校验段头而失败； -
DBMS_STATS.GATHER_TABLE_STATS默认行为安全，但若传了STATTYPE => 'ALL'或启用了INCREMENTAL，内部可能触发本地统计信息写入，报ORA-01642； - 导出用
expdp没问题，但impdp的TABLE_EXISTS_ACTION=TRUNCATE会失败 ——TRUNCATE虽不写数据，但要重置高水位线，Oracle 认定为 DDL 写操作。
真正安全的只有纯 SELECT、CREATE INDEX（索引建在别的读写表空间）、以及 DBMS_METADATA.GET_DDL 这类纯字典查询。
