ORA-01653 是因表空间无足够连续空闲区导致的存储空间不足错误，与语法、权限无关；需检查 DBA_FREE_SPACE 碎片情况、数据文件 autoextensible 属性及磁盘空间，并优先通过 ADD DATAFILE 扩容，辅以大表迁移或 SHRINK 临时缓解，长期应统一使用 LMT+ASSM 表空间管理。
ORA-01653 是空间不够，不是语法或权限问题
这个错误明确告诉你：某张表在插入或更新时，需要分配新数据块，但所在表空间已无连续空闲区（free extent）可用。它和 sql 写错、用户没权限、索引失效都无关，只和 dba_free_space 里剩多少能用的块有关。
- 别急着查应用逻辑——先确认是不是真没空间了：
SELECT tablespace_name, bytes/1024/1024 AS mb_free FROM dba_free_space WHERE tablespace_name = 'YOUR_TS_NAME';
- 注意：
dba_free_space显示的是“空闲区”，不是“空闲页”，即使总空闲量够，但碎片太多（比如只剩一堆 64K 的空闲区，而当前需要 1M extent），照样报 ORA-01653 - 如果表空间是
autoextensible，检查数据文件是否被锁死：SELECT file_name, autoextensible, maxbytes/1024/1024 AS max_mb FROM dba_data_files WHERE tablespace_name = 'YOUR_TS_NAME';
若autoextensible是NO或maxbytes已到上限，扩展就卡住
加数据文件比调大现有文件更稳妥
对生产库来说，往表空间里加新数据文件（ADD DATAFILE）比用 RESIZE 拉伸已有文件风险更低——前者不触发文件系统级重写，也不依赖磁盘剩余空间是否连续。
- 推荐命令：
ALTER TABLESPACE users ADD DATAFILE '/u01/oradata/db/users02.dbf' SIZE 512M AUTOEXTEND ON NEXT 64M MAXSIZE 4G;
- 路径必须由 DBA 确认有写权限且磁盘有足够空间；
SIZE建议设为 512M 或 1G 起步，太小会导致频繁自动扩展，影响性能 - 避免在高峰期执行；加完后立刻查
dba_data_files确认状态是否AVAILABLE，别只看语句没报错就以为成功 - 如果用的是 ASM，路径写法是
+DATA这类磁盘组名，不是 OS 路径，写错会直接报ORA-17502
临时救急：收缩高水位 + 移动大表出问题表空间
当加文件来不及（比如磁盘已满、审批流程长），可临时释放空间，但这是权宜之计，不能替代扩容。
- 先定位吃空间的表：
SELECT segment_name, segment_type, bytes/1024/1024 AS mb FROM dba_segments WHERE tablespace_name = 'YOUR_TS_NAME' ORDER BY bytes DESC FETCH FIRST 5 ROWS ONLY;
- 对非关键大表，可考虑
ALTER TABLE ... MOVE TABLESPACE other_ts，但注意：这会失效原表上的索引，需手动重建；且移动期间表被锁，DML 阻塞 -
SHRINK SPACE COMPACT对堆表有效，但要求表启用了行迁移（ENABLE ROW MOVEMENT），且不能在含 LONG 或未启用 ASSM 的表空间中使用 - 千万别在没备份时直接
TRUNCATE表——ORA-01653 往往发生在业务高峰，误删可能引发更大故障
长期要防碎片：统一用本地管理 + 自动段空间管理（ASSM）
老式字典管理表空间（DMT）和手动段空间管理（MSSM）是 ORA-01653 高发温床，尤其在频繁 DML 的 OLTP 场景下。
- 新建表空间务必用：
CREATE TABLESPACE app_ts DATAFILE '/path/app01.dbf' SIZE 1G EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
关键是结尾的SEGMENT SPACE MANAGEMENT AUTO - 已有 DMT 表空间无法在线转为 LMT，只能导出重建；MSSM 可在线切换：
ALTER TABLESPACE users SEGMENT SPACE MANAGEMENT AUTO;
但切换前所有段必须无活动事务 - ASSM 下 Oracle 自动管理空闲列表（freelists），大幅降低 extent 分配失败概率；不过它会让
dbms_space.space_usage的结果更难解读，监控得换用dba_segments+dba_extents组合查
真正麻烦的不是加文件，而是加完发现表空间里还躺着几个十年前建的、never analyze 过的分区表，每个分区都占着 100M 但实际只存了几条记录——这种隐性空间浪费，监控脚本常常漏掉。
