查dba_extents是最直接方式，它提供段每个区的起始块号、块数、表空间、文件id等完整分配细节，而dba_segments仅汇总段级信息。
查 DBA_EXTENTS 是最直接的方式
Oracle 中段（segment）的每个区（extent）在 DBA_EXTENTS 里都有独立一行记录，这是唯一能拿到“每个区起始块号、块数、表空间、文件 ID”等完整分配细节的视图。注意：必须有 SELECT ANY DICTIONARY 权限或 DBA 角色，普通用户查 USER_EXTENTS 只能看到自己拥有的段。
常见错误是直接查 DBA_SEGMENTS——它只汇总段级信息（总区数、总块数、初始/下一个 extent 大小），不展开单个区。
实操建议：
- 用
SEGMENT_NAME+OWNER+SEGMENT_TYPE精确过滤目标段，避免全表扫描大视图 - 加
ORDER BY FILE_ID, BLOCK_ID能看出区在数据文件中的物理连续性 - 如果查的是索引，注意
SEGMENT_NAME是索引名，不是表名；分区表要额外匹配PARTITION_NAME
DBA_EXTENTS 和 DBA_SEGMENTS 字段差异必须分清
DBA_SEGMENTS 的 EXTENTS 字段是总数，BYTES 是总字节数，而 DBA_EXTENTS 的 BLOCK_ID、BLOCKS、FILE_ID 才是每个区的真实落盘位置。混淆这两者会导致误判碎片程度或定位不到具体坏块。
关键字段对照：
-
DBA_EXTENTS.BLOCK_ID：该区第一个块在文件内的绝对块号（不是相对块号） -
DBA_EXTENTS.BLOCKS：该区占用的连续块数，受表空间ALLOCATION_TYPE（SYSTEM / UNIFORM / AUTOALLOCATE）影响 -
DBA_EXTENTS.RELATIVE_FNO：相对文件号，和V$DATAFILE.RELATIVE_FNO对应，比FILE_ID更稳定（FILE_ID在跨库恢复后可能变化）
查询时容易漏掉分区和 LOB 段
分区表的每个分区、子分区都是独立段，对应多行 DBA_EXTENTS 记录；LOB 段（包括 LOBINDEX 和 LOBSEGMENT）也单独成段。只按表名查会丢掉这些。
实操建议：
- 查分区表：必须关联
DBA_TAB_PARTITIONS或用SEGMENT_NAME = 'TABLE_NAME' AND PARTITION_NAME IS NOT NULL - 查 LOB：先从
DBA_LOBS找到SEGMENT_NAME和INDEX_NAME，再分别去DBA_EXTENTS查——LOB 数据和索引是两个不同段 - 注意
SEGMENT_TYPE值：可能是TABLE PARTITION、INDEX SUBPARTITION、LOBSEGMENT等，不能只认TABLE或INDEX
性能与权限限制下的替代方案
如果没 DBA 权限，又需要估算区分布，USER_EXTENTS 是唯一选择，但只能看到当前用户拥有的对象；如果连这个都不可用，只能退到 USER_SEGMENTS 看汇总值，再结合 DBA_TABLESPACES.ALLOCATION_TYPE 推算典型区大小。
真实场景中更常遇到的是性能问题：DBA_EXTENTS 视图底层依赖 X$KTFBP 等固定表，大库上全扫可能卡住。这时应该：
- 用
OWNER和SEGMENT_NAME加强过滤，避免无条件SELECT * - 避开高峰期执行，尤其不要在 RAC 环境的高并发时段查整个表空间的 extents
- 如果只是想确认是否启用了 ASSM（自动段空间管理），查
DBA_TABLESPACES.SEGMENT_SPACE_MANAGEMENT比扫DBA_EXTENTS快得多
真正难的不是查出数据，而是理解每行 DBA_EXTENTS 记录背后对应的物理存储行为——比如 uniform size 为 1M 的表空间里，一个 8KB 块大小的数据库，每个区固定是 128 块，但实际分配时是否跨文件、是否紧邻前一个区，得结合 FILE_ID 和 BLOCK_ID 手动比对。
