DBA_EXTENTS是唯一能直接反映段物理分布的视图，必须同时查询FILE_ID、BLOCK_ID、BLOCKS三列才能准确判断段的物理连续性与跨文件分布，仅依赖SEGMENT_NAME或BYTES会导致误判。
DBA_EXTENTS 是唯一能直接反映段物理分布的视图，但必须连查 FILE_ID、BLOCK_ID、BLOCKS 三列，缺一不可。只看 SEGMENT_NAME 或 BYTES 会误判连续性或跨文件情况。
查段在表空间内的物理文件分布
目标是确认某个表（或索引）的 extents 是否分散在多个数据文件上，这直接影响 i/o 局部性：
- 执行时必须带上
OWNER和SEGMENT_NAME过滤，否则会混入其他对象的 extent - 聚合时按
FILE_ID分组，不是按TABLESPACE_NAME—— 同一表空间可含多个文件，而段可能只落在其中一部分 - 示例语句：
SELECT owner, segment_name, file_id, COUNT(*) extent_count<br>FROM dba_extents<br>WHERE owner = 'SCHEMA_NAME' AND segment_name = 'TABLE_NAME'<br>GROUP BY owner, segment_name, file_id<br>ORDER BY file_id;
- 若返回多行，说明该段跨文件；单行则全部 extent 都在同一个
FILE_ID上
为什么不能用 BYTES 判断物理连续性
BYTES 是换算值，受 DB_BLOCK_SIZE 影响，且存在四舍五入误差。比如 BLOCKS = 7、块大小为 8192 字节时，BYTES 可能显示为 57344 或 65536（取决于存储对齐），导致 t1.BYTES + t2.BYTES 看似连续，实际 BLOCK_ID 有空隙。
真正判断两个 extent 是否物理相邻，只认这个等式：t1.FILE_ID = t2.FILE_ID AND t1.BLOCK_ID + t1.BLOCKS = t2.BLOCK_ID
常见漏点：
BLOCK_ID 的记录通常是文件头或位图块，不能参与连续性计算- 没加
SEGMENT_NAME条件，把不同段的 extent 错误拼接 - 用
BYTES替代BLOCKS做加减运算
分区表的段分布要先定位到具体分区
分区表的每个分区是一个独立段，DBA_EXTENTS 中每条记录对应一个分区的某个 extent。直接查 SEGMENT_NAME 得到的是分区名（如 TBL_P1），不是基表名。
先查分区归属：
SELECT partition_name, tablespace_name<br>FROM dba_tab_partitions<br>WHERE table_owner = 'SCHEMA_NAME' AND table_name = 'TABLE_NAME';
再查该分区的物理分布：
SELECT file_id, block_id, blocks<br>FROM dba_extents<br>WHERE owner = 'SCHEMA_NAME' AND segment_name = 'TBL_P1';
注意：DBA_TAB_PARTITIONS 只返回已创建且有数据的分区；空分区不会出现，需补查 DBA_TAB_SUBPARTITIONS 或基表默认表空间。
临时段和 UNDO 段不会出现在 DBA_EXTENTS
如果目标是查排序、哈希连接产生的临时段，DBA_EXTENTS 查不到——它只包含永久表空间中的段（SEGMENT_TYPE IN ('TABLE', 'INDEX', 'LOBSEGMENT')）。
对应场景应查：
- 当前活跃临时段：
V$TEMPSEG_USAGE（含SESSION_ADDR、SQL_ID） - UNDO 段：
DBA_UNDO_EXTENTS，不是DBA_EXTENTS - 回滚段（非 UNDO 表空间）：
DBA_ROLLBACK_SEGS
误用 DBA_EXTENTS 查这些对象，结果为空是正常现象，不是权限或视图没刷新的问题。
真正可靠的段分布分析，永远基于 FILE_ID、BLOCK_ID、BLOCKS 三元组。其他字段只是辅助，尤其别信 BYTES 或单独的 EXTENT_ID。
