ORA-01653报错首要排查用户配额是否为0、数据文件autoextensible是否为NO及maxbytes是否过小，而非直接扩容；配额为0、autoextensible=NO或maxbytes不足均会导致报错，即使磁盘充足。
autoextensible = 'NO' 是最常被忽略的配置项
ORA-01653 报错时，很多人第一反应是“磁盘满了”或“表空间真没空间了”，但实际查 dba_data_files 常发现 autoextensible 列值为 'NO'——这意味着 Oracle 根本不会尝试扩展文件，哪怕磁盘还有 100GB 空闲，也会直接报错。
-
autoextensible = 'NO'时，ALTER DATABASE DATAFILE ... RESIZE是唯一解法，不能靠“等它自己长” -
increment_by单位是 Oracle 数据块数（非 KB/MB），默认块大小 8KB，若increment_by = 128，实际每次增长128 × 8 = 1024KB，别误判为“只扩 128 字节” - 新建表空间默认不开启 autoextend，DBA 手动建库脚本里漏写
AUTOEXTEND ON是高频原因
maxbytes 卡在小值上等于“假性开启 autoextend”
看到 autoextensible = 'YES' 就放心？错。如果 maxbytes 被设成 1073741824（即 1GB）或 34359738368（32GB），而当前文件已接近该值，Oracle 就会拒绝分配新 extent，照样触发 ORA-01653。
- 执行
SELECT file_name, bytes/1024/1024 AS curr_mb, maxbytes/1024/1024 AS max_mb FROM dba_data_files WHERE tablespace_name = 'USERS'，对比curr_mb和max_mb -
MAXSIZE UNLIMITED在某些版本或存储类型（如 ASM）下受限，建议显式设为略小于文件系统可用空间的值（例如磁盘剩 50G，设MAXSIZE 40G） - 用
ALTER DATABASE DATAFILE '/path/to/file.dbf' AUTOEXTEND ON MAXSIZE 32G调上限前，务必先df -h确认路径所在挂载点有足够空间
用户配额为 0 导致“表空间有空闲，用户却写不了”
这是最隐蔽的坑：DBA 查 dba_free_space 发现 USERS 表空间还有 2GB 空闲，但用户 SCOTT 插入就报 ORA-01653。根本原因是该用户在该表空间的配额被设为 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 - 新建用户默认
max_bytes = 0，不显式赋 quota 就无法向任何表空间写入数据 - 多租户环境（PDB）下，
dba_ts_quotas必须在当前 PDB 中查询，CDB$ROOT 里查不到 PDB 用户配额
ADD DATAFILE 比 RESIZE 更安全且在线
当确认要扩容时，优先选 ALTER TABLESPACE ... ADD DATAFILE，而不是 RESIZE。前者对业务影响极小，后者会短暂阻塞该文件上所有 DML 操作。
-
ADD DATAFILE是在线操作，无需停业务；RESIZE期间该数据文件上的 INSERT/UPDATE 可能卡住几秒到几十秒 - 路径必须由 DBA 确认 Oracle 用户有写权限，SELinux/AppArmor 未拦截（RHEL/CentOS 常见拦截点）
- ASM 环境路径写
+DATA，不是 OS 路径，写错直接报ORA-17502 -
UNDO和TEMP表空间不支持ADD DATAFILE（12c+ 多租户除外），只能调大现有文件或开 autoextend
