ora-01653 根本原因是目标表空间缺乏足够大的连续空闲区段，需按顺序排查：用户配额是否为0、数据文件autoextensible状态及maxbytes限制、磁盘实际可用空间。
ORA-01653 不是“磁盘满了”或“表空间用光了”这么简单，而是 Oracle 在目标表空间里找不到足够大的连续空闲区段（extent）来满足当前 INSERT/UPDATE 请求——哪怕 dba_free_space 显示还有几百 MB 空闲，也可能因碎片、用户配额为 0 或数据文件卡死而失败。别急着加文件，先按顺序排查这三处。
查用户在目标表空间的配额是否为 0
这是最隐蔽但高频的坑：表空间明明有空闲，用户却报错。新建用户默认 max_bytes = 0，不显式赋权就完全无法写入。
- 运行：
SELECT username, tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'SCOTT' AND tablespace_name = 'USERS'; - 若返回
max_bytes = 0，立即执行：ALTER USER SCOTT QUOTA UNLIMITED ON USERS;（或指定如QUOTA 2G ON USERS） - 多租户环境（PDB）下，
dba_ts_quotas必须在当前 PDB 中查询，不是CDB$ROOT
确认数据文件 autoextensible 状态和 maxbytes 限制
只开 AUTOEXTEND ON 不够，还得看 maxbytes 是不是卡在 1GB、32GB 这类小值上，或者根本就是 NO。
- 查配置：
SELECT file_name, autoextensible, maxbytes/1024/1024 AS max_mb FROM dba_data_files WHERE tablespace_name = 'USERS'; -
autoextensible = 'NO'→ 手动扩容：ALTER DATABASE DATAFILE '/u01/oradata/db/users01.dbf' RESIZE 8192M; -
autoextensible = 'YES'但max_mb接近当前值 → 调上限：ALTER DATABASE DATAFILE '/u01/oradata/db/users01.dbf' AUTOEXTEND ON MAXSIZE 32G; -
autoextensible = 'YES'且MAXSIZE足够，但扩展失败 → 立刻查alert_<sid>.log</sid>，大概率是磁盘已满（报ORA-01119或ORA-27041）
优先 ADD DATAFILE 而不是 RESIZE
对生产库来说，ADD DATAFILE 比 RESIZE 更稳妥——前者在线、不锁 DML、不依赖磁盘连续空间；后者会短暂阻塞该文件上所有写操作，且可能因 HWM 无法缩容。
- 命令示例：
ALTER TABLESPACE users ADD DATAFILE '/u01/oradata/db/users02.dbf' SIZE 512M AUTOEXTEND ON NEXT 64M MAXSIZE 4G; - 路径必须由 DBA 确认有写权限，且 SELinux/AppArmor 未拦截（RHEL/CentOS 常见）
- ASM 环境路径写法是
+DATA，不是 OS 路径，写错直接报ORA-17502 - UNDO 表空间（如
UNDOTBS1）不支持ADD DATAFILE（12c+ 多租户除外），只能调大现有文件或开 autoextend
磁盘空间是否真的够？df -h 和 alert.log 必须一起看
dba_free_space 显示有空闲 ≠ 磁盘真有空间。Oracle 扩展失败常卡在 OS 层。
- 运行：
df -h /u01/oradata查挂载点剩余空间，比如只剩 1.2G，却设MAXSIZE 10G，扩展中途就会卡住 - 同时打开
alert_<sid>.log</sid>，搜索最近的ORA-01119、ORA-27041或 “disk full” 字样 - 注意：NFS 挂载点默认不支持 Oracle 数据文件写入，除非明确配置
hard,nointr,rsize=32768,wsize=32768等参数
真正容易被忽略的是：dba_free_space 不包含未格式化的空间（比如刚扩容但没触发分配的块），所以“有空闲”不等于“能用”；另外，NEXT 值设太大（如 500M）可能瞬间耗尽磁盘，太小（如 1M）又频繁触发扩展影响性能——这个平衡点得结合业务写入节奏来调。
