dba_free_space仅统计已格式化并纳入oracle空闲管理的块，不包含未分配、自动扩展余量及未格式化空间，故返回值常小于实际可用空间。
直接查 dba_free_space 只能拿到“已分配但未使用的块”，不是真正的“剩余可用空间”——它不包含自动扩展关闭、且未被格式化的空闲区域，更不反映 autoextensible=no 表空间的硬上限瓶颈。
为什么 DBA_FREE_SPACE 返回结果经常比实际可用空间小？
这个视图只统计已被 Oracle 格式化、并加入空闲列表（freelist）或位图（bitmap）管理的块。常见脱节场景包括：
-
DBA_DATA_FILES中某文件AUTOEXTENSIBLE=NO，但当前BYTES ，这部分未分配空间 <strong>不会出现在 <code>DBA_FREE_SPACE - 表空间使用
SEGMENT SPACE MANAGEMENT AUTO时，DBA_FREE_SPACE不包含本地管理中由位图跟踪的“未格式化”空闲区 - 刚创建的数据文件，尚未被任何段使用，其全部空间在
DBA_FREE_SPACE中为 0 行 - 执行过
ALTER DATABASE DATAFILE ... RESIZE缩容后，释放的空间需触发一次DBMS_SPACE.FREE_SPACE才可能被识别
真正反映“还能写多少”的查询必须联合 DBA_DATA_FILES
剩余空间应取「当前已分配空闲」+「可自动扩展的未分配空间」的总和。最稳妥的口径是：
SELECT
a.tablespace_name,
ROUND(SUM(a.bytes) / 1024 / 1024, 2) AS total_mb,
ROUND(SUM(NVL(b.free_bytes, 0)) / 1024 / 1024, 2) AS free_allocated_mb,
ROUND(
SUM(NVL(b.free_bytes, 0)) +
SUM(CASE WHEN a.autoextensible = 'YES' THEN a.maxbytes - a.bytes ELSE 0 END)
, 2) / 1024 / 1024 AS real_free_mb,
ROUND(
(SUM(NVL(b.free_bytes, 0)) +
SUM(CASE WHEN a.autoextensible = 'YES' THEN a.maxbytes - a.bytes ELSE 0 END))
/ NULLIF(SUM(a.maxbytes), 0) * 100, 2) AS real_free_pct
FROM dba_data_files a
LEFT JOIN (
SELECT file_id, SUM(bytes) AS free_bytes
FROM dba_free_space
GROUP BY file_id
) b ON a.file_id = b.file_id
GROUP BY a.tablespace_name;
关键点：
-
real_free_mb是运维真正该盯的数字：它包含已分配空闲 + 可扩展余量 -
real_free_pct分母用MAXBYTES而非BYTES，否则对 autoextensible 表空间会严重高估使用率 - 如果某表空间所有数据文件
AUTOEXTENSIBLE=NO，则real_free_mb == free_allocated_mb，此时必须人工介入扩容
Zabbix 或脚本中调用时，sqlplus -S 的坑要提前绕开
用 shell 调 sqlplus 查 DBA_FREE_SPACE 时，以下三点不处理就会丢数据：
- 必须显式设置
set pagesize 0 head off feed off verify off，否则 spool 输出含页眉、分隔线，解析失败 -
dba_free_space查询结果为空时，shell 的$(...)会返回空字符串，导致后续数组长度为 0 —— 需加|| echo "DUMMY"占位再过滤 - Oracle 用户环境变量（如
TNS_ADMIN、ORACLE_SID）在 crond 下不可见，source ~/.bash_profile不一定生效，建议在脚本开头硬编码export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
真正卡住人的从来不是 SQL 写不对，而是把 DBA_FREE_SPACE 当成“磁盘剩余空间”来用 —— 它只是 Oracle 内存管理视角下的空闲块快照，不是文件系统意义上的可用字节。监控告警阈值若只基于它设，等于在悬崖边画安全线。
