ORA-01647报错表明表空间为READ ONLY，禁止任何段扩展；需确认错误源头是否真涉及该只读表空间，再根据场景选择安全绕过方式，如数据泵加TRANSFORM参数、建索引前临时切回READ WRITE、或调整DBMS_STATS参数避免临时段分配。
表空间设为 READ ONLY 后，任何段（包括索引、LOB、临时段）都不允许扩展，ORA-01647 是最直接的报错信号。这不是配置遗漏，而是 Oracle 的硬性限制。
为什么 ALTER TABLESPACE READ ONLY 之后还会遇到段扩展失败？
常见误解是“只读 = 不写”，但实际触发段扩展的操作未必来自显式 DML：
- 某些隐式操作会尝试分配新 extent，比如
CREATE INDEX或ALTER TABLE ... MOVE在只读表空间中执行时，即使目标对象本身在其他表空间，也可能因临时段或日志段依赖而失败 - 全局临时表（
GLOBAL TEMPORARY TABLE）虽不存于只读表空间，但其排序/哈希操作若指定TEMPORARY TABLESPACE为只读表空间（极罕见但可能），也会报错 - 数据泵
impdp导入时若未用TRANSFORM=SEGMENT_ATTRIBUTES:n剥离段属性，且目标表空间为只读，会卡在段创建阶段 - DBMS_STATS 收集统计信息时若启用
method_opt => 'FOR ALL COLUMNS SIZE AUTO'，可能触发直方图临时段分配，同样受限
ORA-01647 出现时该查什么？
先确认错误源头是否真来自只读表空间，而不是误判：
- 查报错 SQL 的执行计划或
v$sql，看是否涉及CREATE、ALTER、INSERT /*+ APPEND */等高概率触发段扩展的操作 - 运行
SELECT tablespace_name, status FROM dba_tablespaces WHERE status = 'READ ONLY';，确认目标表空间名拼写完全一致（大小写敏感） - 查
v$session_longops中状态为EXECUTING且 opname 含segment或extent的记录，定位具体阻塞点 - 注意：
ORA-01647错误信息里会明确带出表空间名，例如ORA-01647: tablespace 'USERS' is read-only, cannot allocate space in it
如何绕过只读限制完成必要操作？
不能强行关闭只读，必须按场景选安全路径：
- 如果是数据泵导入失败，加参数
TRANSFORM=SEGMENT_ATTRIBUTES:n和REMAP_TABLESPACE=OLD_TBS:NEW_TBS，把段创建导向可写的表空间 - 如果是建索引失败，先
ALTER TABLESPACE users READ WRITE，建完立刻切回READ ONLY；切回前确保无活跃事务（v$transaction为空）且所有文件status = 'ONLINE' - 如果是 DBMS_STATS 报错，改用
method_opt => 'FOR ALL COLUMNS SIZE 1'避免自动直方图，或临时切换STATS_TARGET到其他表空间 - 绝对不要用
EVENT 10233或修改数据字典绕过只读检查——这会破坏一致性，备份和恢复将不可靠
最容易被忽略的细节
只读表空间的“冻结”是深度的：不仅禁止写入，还禁用所有与空间管理相关的后台活动。哪怕你有 ALTER TABLESPACE 权限，也无法在只读状态下执行 ALTER TABLE ... ALLOCATE EXTENT 或 SHRINK SPACE。真正需要扩展段的操作，唯一合规解法就是临时切回 READ WRITE，且必须控制窗口期——长事务未提交、归档日志缺失、文件 offline，都会让切回操作 hang 住或失败。
