ORA-01658的根本原因是表空间缺乏足够大的连续空闲块，而非总空间不足；需通过SELECT MAX(BYTES)/1024/1024 FROM DBA_FREE_SPACE确认实际最大连续空闲块大小，再针对性处理。
查当前表空间最大连续空闲块大小
ORA-01658不是总空间不够，而是找不到一块足够大的连续空闲区。DBA_FREE_SPACE里SUM(BYTES)可能还有几GB，但MAX(BYTES)只有64KB——建表时Oracle硬要一次性分一个1MB的INITIAL区，自然失败。
必须先执行这条语句确认真实瓶颈：
SELECT TABLESPACE_NAME, MAX(BYTES) / 1024 / 1024 AS "MAX_MB" FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME = '<code>YOUR_TS_NAME</code>' GROUP BY TABLESPACE_NAME;
- 替换
YOUR_TS_NAME为实际表空间名（如USERS） - 结果
MAX_MB若小于你要创建对象的INITIAL值（比如脚本里写了STORAGE(INITIAL 2M)），就别急着加文件，先看碎片 - 别只查
DBA_DATA_FILES.BYTES——那是文件总大小，不反映内部是否能用
临时绕过：显式指定更小的INITIAL值
如果DDL卡在上线前、又没权限清理或扩容，压低INITIAL是最快见效的手段。这不是妥协，是让请求匹配当前可用连续块的真实能力。
- 建表时加
STORAGE(INITIAL 64K)：例如CREATE TABLE t(x INT) STORAGE(INITIAL 64K) - 避免隐式放大：不写
STORAGE子句时，Oracle可能按表空间默认值推算出1MB甚至10MB，远超需要 - 批量改脚本可用正则：
STORAGE\(.*INITIAL [0-9]+[MG]\)→STORAGE(INITIAL 64K)，注意避开注释和字符串 -
SEGMENT CREATION DEFERRED（11gR2+）也有效：CREATE TABLE t(x INT) SEGMENT CREATION DEFERRED，首次INSERT才分配，彻底跳过建表阶段的INITIAL申请
根治方案：清理碎片或横向扩容
频繁报ORA-01658说明表空间长期未维护。盲目RESIZE数据文件或设AUTOEXTEND ON NEXT 10M反而加剧碎片——小块追加到末尾，MAX(BYTES)会越来越小。
- 优先
ALTER TABLESPACE ... ADD DATAFILE：新增文件不依赖现有碎片，只要磁盘有空间、用户有权限就能立刻缓解 - 新文件推荐配置：
AUTOEXTEND ON NEXT 100M MAXSIZE 32G，避免后续反复扩容 - 清理回收站：
PURGE RECYCLEBIN，被DROP的对象仍占空间 - 删废弃段：
SELECT SEGMENT_NAME, SEGMENT_TYPE, BYTES/1024/1024 MB FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = '<code>YOUR_TS_NAME' ORDER BY BYTES DESC FETCH FIRST 10 ROWS ONLY，定位大而闲的对象 -
ASSM表空间下COALESCE无效，真要收缩得用ALTER TABLE ... SHRINK SPACE COMPACT（需先ENABLE ROW MOVEMENT）
换表空间前务必验证目标空间是否真“干净”
不能因为名字叫USERS就默认它连续块充足。很多环境里USERS反而是最碎的——测试表、临时导出表堆满后又被删，留下大量小空洞。
- 先查目标表空间的
MAX(BYTES)：SELECT MAX(BYTES)/1024/1024 FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME = '<code>USERS' - 再确认非
READ ONLY：SELECT STATUS FROM DBA_TABLESPACES WHERE TABLESPACE_NAME = '<code>USERS' - 如果目标表空间也是
ASSM且HWM偏高，即使MAX(BYTES)够，也可能因bitmap block争用失败——此时换空间只是把问题转移
MAX(BYTES)这一步跳不过，否则扩容、清理、换空间都可能白忙。 
