最常见原因是dba_data_files.bytes记录逻辑大小而非os真实占用，如resize后os文件未同步缩小导致“已用空间”虚高。
dba_data_files.bytes 和实际文件大小不一致
表空间容量统计不准，最常见原因是 dba_data_files.bytes 记录的是数据文件“逻辑大小”，不是 OS 层真实占用。比如你用 ALTER DATABASE DATAFILE ... RESIZE 10G 调小了文件，Oracle 会更新 bytes 字段，但 OS 文件可能仍保留原大小（尤其在未启用 SHRINK 或未使用 REUSE 的情况下）。此时查询出来的“已用空间”会虚高。
dba_free_space 视图未及时刷新或被跳过
dba_free_space 只反映 *当前可用的空闲 extent*，但它依赖于本地管理位图（LMT）状态。如果发生以下情况，该视图数据就不可信：
- 表空间是 dictionary-managed（极少见，但老系统可能存在），
dba_free_space不维护或严重滞后 - 执行过大量 DML 后未提交，或者事务长时间未结束，空闲空间被“预占”但未释放
- 使用了 ASSM（Automatic Segment Space Management）且存在 high-water mark 偏移，特别是 shrink 操作后未 update statistics
典型现象：SELECT SUM(bytes) FROM dba_free_space 返回 0，但实际磁盘还有空间——说明空闲块没被位图标记为 free。
autoextensible=YES 但 maxsize 已到上限却未报错
这是最容易被忽略的“假充足”陷阱。比如你设了 AUTOEXTEND ON NEXT 100M MAXSIZE 32G，而文件当前已是 32G，dba_data_files.maxbytes 就等于 bytes。此时虽然 autoextensible 是 YES，但已无扩展余地。查询 dba_data_files 时若只看 autoextensible 列，会误判“还能自动增长”。
必须同时检查：
bytes == maxbytesmaxbytes （预留缓冲）- Windows 下单个
.dbf文件是否已达 32GB 上限（NTFS 限制）
临时表空间或 UNDO 表空间被错误套用通用统计逻辑
很多人用查普通表空间的方法去算 TEMP 或 UNDOTBS1 的“剩余空间”，结果完全失真。原因：
-
dba_free_space对 TEMP 表空间无效——它显示的是 sort segment 的空闲，不是文件级剩余 - UNDO 表空间的“可用性”取决于
undo_retention和活跃事务，不是简单减法 -
dba_temp_files和dba_undo_extents才是对应视图，混用会得出荒谬结论
例如：SELECT SUM(bytes) FROM dba_free_space WHERE tablespace_name = 'TEMP' 几乎总是 0，但这不代表 temp 空间用完了。
dba_data_files 当成磁盘 du 命令。
