DBA_SEGMENTS单查segment_name会严重低估表真实空间占用，因其仅返回TABLE类型段，遗漏LOB段、索引段及分区子段；必须通过关联DBA_LOBS和DBA_INDEXES三路聚合才能准确统计。
只查 DBA_SEGMENTS 里的 segment_name = 'XXX'，得到的数值大概率比实际小 2–5 倍。真实占用必须把表段、LOB 段、索引段三者分开查、再加总，否则容量规划和磁盘告警都会失真。
为什么 dba_segments 单查会严重低估？
一张业务表的空间开销从来不是“一个段”的事：DBA_SEGMENTS 中 SEGMENT_TYPE = 'TABLE' 只反映堆表本体，但真实存储压力常藏在三个地方：
-
LOBSEGMENT：每个CLOB/BLOB字段默认生成独立 LOB 段，名字像SYS_LOB0000123456$，无法靠表名猜测，必须通过DBA_LOBS关联 -
INDEX或INDEX PARTITION：主键、唯一约束、普通索引都单独成段；分区索引还会拆成多个子段 - 表本身如果是分区表，
TABLE PARTITION和TABLE SUBPARTITION也得单独计入，不能只看TABLE类型那一条
常见错误现象：执行 SELECT bytes FROM DBA_SEGMENTS WHERE segment_name = 'ORDER_HEADER' 返回 1.2GB，但磁盘监控显示该用户下增长了 8GB —— 很可能漏掉了 3 个 LOB 段（各 2GB+）和 2 个全局索引。
怎么用 SQL 一次性汇总表 + LOB + 索引的真实大小？
核心是三路 JOIN 或 UNION ALL 聚合，不能只靠 WHERE segment_name = 'XXX'。以下语句在 DBA 权限下可直接运行（注意替换 OWNER 和 TABLE_NAME）：
SELECT
t.owner,
t.table_name,
ROUND(SUM(CASE WHEN s.segment_type LIKE 'TABLE%' THEN s.bytes ELSE 0 END) / 1024 / 1024 / 1024, 2) AS table_gb,
ROUND(SUM(CASE WHEN s.segment_type = 'LOBSEGMENT' THEN s.bytes ELSE 0 END) / 1024 / 1024 / 1024, 2) AS lob_gb,
ROUND(SUM(CASE WHEN s.segment_type LIKE 'INDEX%' THEN s.bytes ELSE 0 END) / 1024 / 1024 / 1024, 2) AS idx_gb,
ROUND(SUM(s.bytes) / 1024 / 1024 / 1024, 2) AS total_gb
FROM DBA_TABLES t
JOIN DBA_SEGMENTS s ON (
(s.segment_type LIKE 'TABLE%' AND s.segment_name = t.table_name AND s.owner = t.owner)
OR
(s.segment_type = 'LOBSEGMENT' AND s.segment_name IN (
SELECT l.segment_name FROM DBA_LOBS l
WHERE l.table_name = t.table_name AND l.owner = t.owner
))
OR
(s.segment_type LIKE 'INDEX%' AND s.segment_name IN (
SELECT i.index_name FROM DBA_INDEXES i
WHERE i.table_name = t.table_name AND i.owner = t.owner
))
)
WHERE t.owner = 'SCHEMA_NAME' AND t.table_name = 'ORDER_HEADER'
GROUP BY t.owner, t.table_name;
关键点：
- 必须显式关联
DBA_LOBS和DBA_INDEXES，不能依赖段名模糊匹配 -
SEGMENT_TYPE LIKE 'TABLE%'覆盖TABLE、TABLE PARTITION、TABLE SUBPARTITION - 如果权限受限，改用
USER_*视图，但只能查当前用户对象
什么时候该用 dbms_space.object_space_usage？
这个函数不解决“汇总”问题，而是诊断单个段内部空间是否健康。它返回已用字节、分配字节、链式行百分比，适合排查高水位线（HWM）卡死、行迁移这类问题：
DECLARE
su NUMBER; sa NUMBER; cp NUMBER;
BEGIN
dbms_space.object_space_usage(
segment_owner => 'SCHEMA_NAME',
segment_name => 'ORDER_HEADER',
segment_type => 'TABLE',
used_bytes => su,
alloc_bytes => sa,
chain_percent => cp
);
dbms_output.put_line('Used: ' || ROUND(su/1024/1024, 2) || ' MB');
dbms_output.put_line('Alloc: ' || ROUND(sa/1024/1024, 2) || ' MB');
dbms_output.put_line('Chain%: ' || cp);
END;
典型使用场景：
-
used_bytes远小于alloc_bytes→ 表存在大量空闲块，可考虑ALTER TABLE ... SHRINK SPACE -
chain_percent> 5% → 行迁移严重，需检查INITRANS、PCTFREE或重建表 - 只对单个段有效，不自动包含 LOB 或索引 —— 这是它和全景统计的根本区别
最易被忽略的一点：即使你跑通了上面的聚合 SQL，如果表有物化视图日志、IOT 的 overflow 段、或者域索引（Oracle Text），这些仍不会被计入。真实生产环境里，先确认这张表有没有启用高级功能，再决定是否要额外查 DBA_MVIEW_LOGS 或 DBA_LOB_PARTITIONS。
