ORA-01653根本原因是找不到足够大的连续空闲区段，须按序排查用户配额是否为0、数据文件autoextensible状态及maxbytes限制、磁盘实际可用空间；配额为0最隐蔽，autoextensible=NO或maxbytes不足均会导致报错。
ORA-01653 不是“表空间满了”，而是 Oracle 找不到足够大的连续空闲区段来分配新 extent——哪怕 DBA_FREE_SPACE 显示还有几百 MB，也可能因用户配额为 0、数据文件被卡死在 MAXSIZE、或磁盘真实已满而失败。必须按固定顺序排查，跳过任一环节都可能白忙活。
查用户在目标表空间的配额是否为 0
这是最隐蔽但最高频的根因：表空间明明有空闲，SCOTT 却报 ORA-01653。新建用户默认 max_bytes = 0，不显式赋 QUOTA 就完全无法写入。
- 执行：
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 状态和 MAXSIZE 是否合理
只开 AUTOEXTEND ON 不够，关键是 MAXSIZE 是否被设成 1GB、32GB 这类小值，或者根本就是 NO。
- 查配置：
SELECT file_name, autoextensible, maxbytes/1024/1024 AS max_mb, bytes/1024/1024 AS curr_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接近curr_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 -
UNDOTBS1等 UNDO 表空间不支持ADD DATAFILE（12c+ 多租户除外），只能调大现有文件或开AUTOEXTEND
磁盘空间是否真的够？df -h 和 alert.log 必须一起看
df -h 显示有空间 ≠ Oracle 能用：可能是挂载点权限问题、SELinux 拦截、或文件系统级碎片导致无法创建大文件。
- 执行：
df -h /u01/oradata（对应数据文件所在挂载点） - 同步检查：
tail -50 $ORACLE_BASE/diag/rdbms/*/alert/*.log | grep -i "ORA-01119\|ORA-27041\|ORA-17502" - 若日志中出现
ORA-01119: error in creating database file，基本可断定是操作系统层无空间或权限问题 - 注意：某些旧文件系统（如 ext3）单文件有 2GB 限制，虽已过时，但在老旧环境仍需验证
真正棘手的不是加文件，而是配额为 0 或 MAXSIZE 卡死这种“看不见的墙”——它们不会在 DBA_FREE_SPACE 里暴露，却让所有自动扩展逻辑彻底失效。每次处理前，先跑两行 SQL 确认配额和 MAXSIZE，比盲目扩容快十倍。
