不能只查dba_tablespaces因其不存空间占用数据，真实使用率需通过dba_data_files与dba_segments联算，且须过滤非永久表空间、补null、统一单位并设告警阈值。
为什么不能只查 DBA_TABLESPACES 就算完
查出来全是 0% 或直接报 ORA-01476: divisor is equal to zero——这是最典型的“脚本跑通但结果无用”现象。因为 DBA_TABLESPACES 只存状态（STATUS）和类型（CONTENTS），不存任何空间占用数据。真实使用率必须靠物理文件大小减去已分配段空间来推算。
- 主表必须是
DBA_DATA_FILES，且要加WHERE STATUS = 'AVAILABLE'过滤掉异常文件（如脱机、损坏、只读） -
DBA_SEGMENTS汇总的是已分配的段空间，不含临时段、UNDO 段、SYS 内部对象（如SYS.AUD$分区），所以是近似值，但足够用于巡检 - 空表空间（没任何 segment）会导致
LEFT JOIN后usedsize为 NULL，必须用NVL(s.usedsize, 0)补零，否则整行被丢弃 - 所有
BYTES必须统一除以1024 / 1024转 MB，别混用 KB/GB，小数点后保留一位即可，报表才可读
怎么写一条能落地的巡检 SQL（带告警标记）
下面这条 SQL 直接输出可用率 + 状态标记，可重定向到 CSV 或 spool 成文本报表，无需额外处理：
SELECT t.tablespace_name,
ROUND(d.totalsize / 1024 / 1024, 1) AS "TOTAL_MB",
ROUND(NVL(s.usedsize, 0) / 1024 / 1024, 1) AS "USED_MB",
ROUND((NVL(s.usedsize, 0) / d.totalsize) * 100, 1) AS "PCT_USED",
CASE WHEN (NVL(s.usedsize, 0) / d.totalsize) >= 0.9 THEN 'CRITICAL'
WHEN (NVL(s.usedsize, 0) / d.totalsize) >= 0.8 THEN 'WARNING'
ELSE 'OK' END AS "STATUS"
FROM DBA_TABLESPACES t
JOIN (SELECT tablespace_name, SUM(bytes) AS totalsize
FROM DBA_DATA_FILES
WHERE STATUS = 'AVAILABLE'
GROUP BY tablespace_name) d
ON t.tablespace_name = d.tablespace_name
LEFT JOIN (SELECT tablespace_name, SUM(bytes) AS usedsize
FROM DBA_SEGMENTS
GROUP BY tablespace_name) s
ON t.tablespace_name = s.tablespace_name
WHERE t.contents = 'PERMANENT'
ORDER BY "PCT_USED" DESC;
- 过滤掉
t.contents != 'PERMANENT'，避免把 TEMP、UNDO 表空间混进来干扰判断 - 不要用
DBA_FREE_SPACE计算剩余空间——大文件表空间（bigfile）下该视图可能为空，导致计算失败 - 告警阈值设为 80% 和 90%，比 Oracle 默认的 60%/68% 更贴近生产实际：太敏感会误报，太宽松会漏风险
- 执行前确保用户有
SELECT_CATALOG_ROLE或直接GRANT SELECT ON SYS.DBA_* TO your_user
巡检时必须连带验证的三类边界场景
表空间使用率数字只是表象，真正要防的是背后不可扩展、不可清理、不可扩容的硬瓶颈。
-
df -h查物理磁盘：如果挂载点已超 90%，加数据文件也无效，得先清理归档或回收站（PURGE DBA_RECYCLEBIN） - 查自动扩展是否启用：
SELECT tablespace_name, file_name, autoextensible, maxbytes FROM DBA_DATA_FILES；若AUTOEXTENSIBLE = 'NO'且PCT_USED > 85%，必须人工干预 - 查是否有大对象卡住空间释放：比如未 purge 的 LOB 段、长期未提交的事务回滚段，仅靠
DBA_SEGMENTS算不出这部分“隐形占用”
段空间碎片怎么快速识别（不用等 AWR 报告）
高水位线（HWM）附近大量空闲块无法复用，会导致明明还有空间却频繁报 ORA-01653。用这条 SQL 快速定位可疑对象：
SELECT owner, segment_name, segment_type,
ROUND(bytes/1024/1024, 1) "SIZE_MB",
blocks, extents,
ROUND((blocks * 8192 / bytes) * 100, 1) "UTIL_PCT"
FROM DBA_SEGMENTS
WHERE bytes > 100*1024*1024
AND segment_type IN ('TABLE', 'INDEX')
AND (blocks * 8192 / NULLIF(bytes, 0))
-
UTIL_PCT低于 30% 表示物理块利用率极低，大概率存在严重碎片（尤其对频繁 DELETE/UPDATE 的表） - 重点盯
SEGMENT_TYPE = 'TABLE'且EXTENTS > 50的对象，这类表容易因 PCTINCREASE 或手动 FREELISTS 设置不当造成空间浪费 - 别一上来就
ALTER TABLE ... MOVE，先确认业务低峰期，并检查该表是否有物化视图日志、函数索引等依赖项
真正难的不是算出百分比，而是判断这个百分比背后有没有“动不了”的约束——比如磁盘满了、权限卡了、参数锁了、或者 DBA 忘了关自动扩展。巡检脚本再准，也得人眼核对上下文。
