直接按OWNER分组求和BYTES错误，因同一schema对象分散在不同表空间且段类型混杂；正确做法是过滤TABLE/LOBSEGMENT/INDEX并关联表空间与schema归属。
不能直接按 owner 分组求和 bytes，否则结果严重失真——因为一个 schema 的对象（表、索引、lob）天然分散在多个表空间，且 dba_segments 包含所有段类型，混在一起统计等于把“房子+地基+车库”全算成建筑面积。
为什么 GROUP BY OWNER + SUM(BYTES) 是错的
常见错误写法：SELECT owner, SUM(bytes)/1024/1024 AS mb FROM dba_segments GROUP BY owner。它看起来快，但掩盖了三个关键事实：
-
OWNER是逻辑 schema 名，不是物理归属单位；同一OWNER的TABLE可能在USERS表空间，其INDEX在INDEXES，LOBSEGMENT又在LOB_TBS -
DBA_SEGMENTS包含'TABLE'、'INDEX'、'LOBSEGMENT'、'TABLE PARTITION'等十余种SEGMENT_TYPE，不加区分会导致重复计数（比如分区表的每个分区都算一次）或误判（如把临时索引当业务数据） - 大量无效索引、历史分区、未清理的 LOB 段会显著拉高数值，让你以为某个业务库“膨胀”了，其实只是没人管的垃圾
正确做法：按 segment_type 过滤 + 显式关联表空间归属
要回答“各 Schema 在不同表空间中实际占了多少”，核心是聚焦三类业务相关段，并保留 TABLESPACE_NAME 维度：
-
SEGMENT_TYPE = 'TABLE'：对应真实业务表的数据段（不含 LOB 内容） -
SEGMENT_TYPE = 'LOBSEGMENT'：必须和所属表的OWNER和SEGMENT_NAME关联，否则无法归属到具体业务 Schema -
SEGMENT_TYPE = 'INDEX'：需通过DBA_INDEXES查TABLE_OWNER，才能把索引空间回溯到原表所属 Schema；直接查DBA_SEGMENTS里的OWNER字段会得到索引自己的 owner（通常是同 schema，但不可依赖）
推荐用这个语句（需 DBA 权限）：
SELECT
ds.owner,
ds.tablespace_name,
ds.segment_type,
ROUND(SUM(ds.bytes) / 1024 / 1024, 2) AS mb
FROM dba_segments ds
WHERE ds.segment_type IN ('TABLE', 'LOBSEGMENT', 'INDEX')
AND ds.owner NOT IN ('SYS', 'SYSTEM') -- 排除系统用户
GROUP BY ds.owner, ds.tablespace_name, ds.segment_type
ORDER BY ds.owner, ds.tablespace_name, mb DESC;ORA-00942 报错时怎么办
执行上面 SQL 报 ORA-00942: 表或视图不存在，说明当前用户没权限访问 DBA_SEGMENTS 或 DBA_INDEXES：
- 如果是运维人员，用有
SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY权限的账号执行 - 如果是普通开发账号，让 DBA 执行：
GRANT SELECT ANY DICTIONARY TO your_user; - 若无法授 DBA 权限，可改用
USER_SEGMENTS和USER_INDEXES，但只能查当前用户下的对象，看不到跨 schema 占比
注意 LOBSEGMENT 的归属陷阱
DBA_SEGMENTS 中的 LOBSEGMENT 的 SEGMENT_NAME 是系统生成的（如 SYS_LOB0000098789C00005$$），无法直接看出属于哪张表。必须用 DBA_LOBS 关联：
SELECT owner, table_name, column_name, segment_name FROM dba_lobs WHERE owner = 'MYSCHEMA';- 再用该
segment_name去DBA_SEGMENTS中匹配，才能把 LOB 空间准确归到业务表和 schema 下 - 跳过这步，
LOBSEGMENT就是“幽灵段”——知道它占了空间，但不知道是谁家的
真正要算清占比，LOB 必须回填到原始表的 OWNER 和 TABLESPACE_NAME，否则 “某 Schema 在某表空间占比” 就永远缺一块。
