oracle表空间逻辑满而磁盘物理空闲，主因是数据文件autoextensible关闭或maxbytes已达上限；需查dba_data_files确认autoextensible状态及maxbytes值，并验证oracle用户对文件路径的写权限与selinux策略。
Oracle表空间显示已满，但操作系统 df -h 显示磁盘仍有大量空闲——这不是幻觉，而是典型的“逻辑满 vs 物理满”错位。根本原因在于：表空间的容量由其下属数据文件（dba_data_files）定义，与磁盘剩余空间无直接等价关系；即使磁盘宽裕，只要这些文件本身无法再增长或已触顶，表空间就“满了”。
查 dba_data_files 的 AUTOEXTENSIBLE 和 MAXBYTES
这是最常被忽略的第一环。很多 DBA 看到磁盘有空间，就默认 autoextend 能起作用，却忘了检查它是否真开着、上限是否卡死了。
-
AUTOEXTENSIBLE = 'NO'：文件完全不会自己长大，哪怕磁盘剩 1TB 也无济于事 -
AUTOEXTENSIBLE = 'YES'但MAXBYTES = BYTES（即当前大小等于最大大小）：已涨到头，再没扩展余地 -
MAXBYTES是字节值，不是 MB；例如显示34359738368就是 32GB，别误读成 32MB
执行这个 SQL 快速定位：
SELECT file_name, bytes/1024/1024 "curr_mb", maxbytes/1024/1024 "max_mb", autoextensible FROM dba_data_files WHERE tablespace_name = 'YOUR_TBS_NAME';
确认磁盘路径和 Oracle 用户写权限
即使 AUTOEXTENSIBLE = YES 且 MAXBYTES 足够，Oracle 仍可能在扩展时失败——因为根本写不进那个目录。
- 用
SELECT file_name FROM dba_data_files WHERE tablespace_name = 'YOUR_TBS_NAME'拿到真实路径，再跑df -h /u01/oradata/PROD（替换成你路径的父目录） - 检查 Oracle OS 用户对该路径是否有写权限：
ls -ld /u01/oradata/PROD；若属组不对或无 w 权限，ALTER DATABASE DATAFILE ... AUTOEXTEND ON会静默失效或报ORA-01119 - RHEL/CentOS 上 SELinux 可能拦截写入，临时验证可运行
setenforce 0（仅测试），生产环境需配对semanage fcontext
dba_free_space 显示有空闲块，但插入仍报 ORA-01653
这说明问题不在总量，而在“连续性”——Oracle 分配空间需要连续的 extent，而碎片化会让大块请求失败。
- 执行
SELECT tablespace_name, COUNT(*), SUM(bytes)/1024/1024 "mb" FROM dba_free_space GROUP BY tablespace_name：如果COUNT(*)很大（比如上千）、单个mb却很小（ - 此时加文件（
ADD DATAFILE）比RESIZE更有效：新文件提供全新连续空间，绕过旧文件碎片 - 不要依赖
RESIZE回收空间：它只能缩到高水位线（HWM）以下，而 HWM 不因 delete 下降；想真正释放，得ALTER TABLE ... MOVE或SHRINK SPACE
用户配额（QUOTA）为 0 是最隐蔽的“假满”
表空间明明还有几十 GB 空闲，某个用户却插不进数据？大概率是他的配额被设成了 0。
- 查配额：
SELECT username, tablespace_name, bytes/1024/1024 "quota_mb" FROM dba_ts_quotas WHERE tablespace_name = 'YOUR_TBS_NAME' - 配额为
0或NULL表示禁止使用该表空间，即使表空间本身充裕也不行 - 修复命令：
ALTER USER your_user QUOTA UNLIMITED ON your_tbs或QUOTA 1024M ON your_tbs - 该问题在多租户或严格权限管控环境中高频出现，且错误日志里不提示配额，只报
ORA-01653
真正棘手的从来不是“没空间”，而是“空间在那里，但 Oracle 看不见、用不上”。每次遇到 ORA-01653，优先按顺序验这四点：autoextend 开关与上限 → 磁盘路径与权限 → 碎片分布 → 用户配额。漏掉任意一环，都可能让扩容操作变成无效动作。
