DBA_EXTENTS的BLOCK_ID是数据文件内的起始物理块号，非逻辑序号或操作系统偏移；判断段跨文件需查FILE_ID是否唯一；临时段和回滚段不在DBA_EXTENTS中。
直接查 dba_extents 能看到段的物理分布，但必须连带 file_id、block_id、blocks 三列一起看，单看某一项会误判连续性。
DBA_EXTENTS 的 BLOCK_ID 是物理块号还是逻辑块号
BLOCK_ID 是数据文件内的**起始物理块号**，不是段内逻辑序号，也不是操作系统偏移。它和 DBA_FREE_SPACE.BLOCK_ID 含义一致，可直接比对是否相邻。但注意：这个值在 bigfile 表空间下仍为 32 位范围（0～4G-1），不反映文件总大小；smallfile 下更直观。别用它去算“第几个 extent”，那是 EXTENT_ID 的事。
怎么判断一个段是否跨多个数据文件
执行以下查询，重点看 FILE_ID 是否唯一：
SELECT segment_name, owner, file_id, COUNT(*) extent_count FROM dba_extents WHERE segment_name = 'YOUR_TABLE' AND owner = 'SCHEMA_NAME' GROUP BY segment_name, owner, file_id;
如果返回多行，说明该段确实跨文件——常见于手动指定了多个数据文件的表空间，或启用了 AUTOALLOCATE + 大对象自动扩展。此时 I/O 可能分散，但 Oracle 自动管理，无需人工干预，除非观察到 v$filestat 中对应文件的 phyrds 明显不均。
为什么查 DBA_EXTENTS 看不到临时段或回滚段
-
DBA_EXTENTS默认只包含永久表空间中的段（SEGMENT_TYPE IN ('TABLE', 'INDEX', 'LOBSEGMENT', 'CLUSTER'等） - 临时段走
V$TEMP_EXTENT_POOL或V$SORT_SEGMENT，回滚段（非 UNDO 表空间）需查DBA_ROLLBACK_SEGS，UNDO 段则在DBA_UNDO_EXTENTS - 如果目标是查某个 SQL 执行时生成的临时排序段，得结合
V$SQL_WORKAREA_ACTIVE和V$TEMPSEG_USAGE，而不是翻DBA_EXTENTS
BLOCK_ID + BLOCKS 连续性验证容易漏掉的点
两个 extent 物理连续，当且仅当：t1.FILE_ID = t2.FILE_ID 且 t1.BLOCK_ID + t1.BLOCKS = t2.BLOCK_ID。但实操中常踩三个坑：
- 没过滤掉文件头保留块：
BLOCK_ID 的记录通常是文件头或位图块，不能参与连续性计算 - 忽略
OWNER和SEGMENT_NAME条件，导致把不同对象的 extent 错误拼接 - 用
BYTES替代BLOCKS做加减——BYTES是换算值，受DB_BLOCK_SIZE影响，且可能因四舍五入失真（例如 8192 × 7 = 57344，但显示为 57344 或 65536）
真正可靠的连续性判断，永远基于 FILE_ID、BLOCK_ID、BLOCKS 三元组，其他字段只是辅助。
