查dba_extents必须指定owner和segment_name，否则全表扫描数据字典；分区表、lob、索引等对应独立段，需联合dba_indexes、dba_lobs、dba_tab_partitions等视图获取全部段名，再通过file_id关联v$datafile定位物理路径。
查DBA_EXTENTS必须带OWNER和SEGMENT_NAME过滤
不加条件直接查DBA_EXTENTS会全表扫描数据字典基表，大库中可能卡住几秒甚至更久。真实场景里，你要定位的是某张表的物理分布，所以第一件事就是锁定归属和对象名。
常见错误是只写SEGMENT_NAME = 'TBL_NAME'，漏掉OWNER——结果可能返回多个用户下同名对象的区，或者干脆没结果（权限不足或对象不在当前用户下）。
-
OWNER必须明确指定，比如'SCOTT'，不能依赖当前登录用户 - 如果表是分区表，
SEGMENT_NAME不是表名，而是分区名，得先查DBA_TAB_PARTITIONS拿到PARTITION_NAME再代入 - LOB列对应的段名也不等于表名，得从
DBA_LOBS查SEGMENT_NAME
一个表可能对应多个段类型，别只盯SEGMENT_TYPE = 'TABLE'
只查SEGMENT_TYPE = 'TABLE'会漏掉真实占用空间的物理结构。一张带CLOB字段、主键索引和分区的表，实际在磁盘上至少有4个独立段：主表段、索引段、LOB段、分区段——每个段都有自己的FILE_ID和BLOCK_ID范围。
正确做法是联合查出所有相关段名：
- 主表段：
SEGMENT_NAME= 表名 - 索引段：查
DBA_INDEXES中TABLE_OWNER和TABLE_NAME匹配的INDEX_NAME - LOB段：查
DBA_LOBS中OWNER和TABLE_NAME匹配的SEGMENT_NAME - 分区段：若为分区表，
SEGMENT_NAME=PARTITION_NAME，需从DBA_TAB_PARTITIONS获取
否则你看到的只是“冰山一角”，比如LOB数据全在另一个文件里，但查询结果里完全没体现。
用FILE_ID关联v$datafile看真实物理路径
DBA_EXTENTS.FILE_ID是数据文件编号，它和v$datafile.FILE_ID语义一致，可直接等值连接。但注意：v$datafile里没有FILE#字段——那是控制文件里的序号，重启后可能变，不能用于跨会话定位。
典型查询模式如下：
SELECT e.SEGMENT_NAME, e.SEGMENT_TYPE, e.FILE_ID, d.NAME, e.BLOCK_ID, e.BLOCKS
FROM DBA_EXTENTS e
JOIN v$datafile d ON e.FILE_ID = d.FILE_ID
WHERE e.OWNER = 'SCOTT'
AND e.SEGMENT_NAME IN ('EMP', 'EMP_PK', 'SYS_LOB0000092325C00003$$');
如果NAME列为空或查不到文件，说明该段可能在临时表空间（查v$tempfile）或UNDO表空间（查v$rollname），不是常规数据文件。
分区表的extent分布天然分散，别指望TABLESPACE_NAME字段
DBA_TABLES.TABLESPACE_NAME只存默认表空间，对分区表完全不可靠。一个分区表的10个分区可以分别落在5个不同表空间里，每个分区又是独立段，DBA_EXTENTS里每条记录都带FILE_ID和BLOCK_ID，这才是真实物理分布图谱的原子单位。
容易被忽略的点：
- 空分区不会出现在
DBA_TAB_PARTITIONS里，得补查DBA_TAB_SUBPARTITIONS或直接查DBA_SEGMENTS确认是否存在对应段 -
DBA_EXTENTS不包含字典管理表空间的区信息，确认对象是否在本地管理表空间（DBA_TABLESPACES.SEGRMENT_SPACE_MANAGEMENT = 'LOCAL'） - 想看“连续性”，光看
BLOCK_ID不够，还要结合BLOCKS算出结束块号：BLOCK_ID + BLOCKS - 1，才能判断是否跨文件或存在空洞
物理分布图谱的本质，是把每个段、每个分区、每个索引、每个LOB，还原成FILE_ID + BLOCK_ID + BLOCKS三元组——其它字段都是辅助解释，不能替代这组数字。
