dba_extents不能主动发现坏块，仅能根据已知文件号和块号定位所属段；它只存储段的物理范围元数据，不校验块内容是否损坏。
能查，但不能直接靠 dba_extents 发现坏块本身——它只负责定位坏块落在哪个段上，前提是已知文件号和块号。
为什么 DBA_EXTENTS 不能主动“扫描”坏块
DBA_EXTENTS 是元数据视图，记录的是段（表、索引等）在数据文件中的物理分布范围（BLOCK_ID 到 BLOCK_ID + BLOCKS - 1），它不校验数据块内容是否损坏。也就是说，它不包含“这个块是不是坏的”信息，只回答“这个块属于谁”。
常见错误现象：执行 SELECT * FROM DBA_EXTENTS WHERE file_id = 5 AND 1289 BETWEEN block_id AND block_id + blocks - 1 返回空，可能因为：
- 块号
1289实际属于某个临时段（TEMPFILE中的块不会出现在DBA_EXTENTS） - 该块位于段头（segment header）或高水位线以上未格式化的空间
- 表空间是本地管理（LMT）且使用位图，而块尚未被分配给任何段
必须先拿到 file_id 和 block_id 才能用 DBA_EXTENTS
这两个值通常来自报错或检测工具，不是凭空猜的。典型来源包括：
-
ORA-01578错误消息里明确带出：(file # 5, block # 1289) -
v$database_block_corruption视图实时记录已确认的坏块（需BACKUP VALIDATE CHECK LOGICAL或 RMAN 扫描后填充） -
dbv工具输出中 “Total Pages Marked Corrupt : X” 对应的具体file和block
示例查询（注意变量替换）：
SELECT owner, segment_name, segment_type, tablespace_name FROM dba_extents WHERE file_id = 5 AND 1289 BETWEEN block_id AND block_id + blocks - 1;
如果返回结果为空，别急着怀疑语句，先确认：file_id = 5 是否对应数据文件（查 dba_data_files），而不是临时文件（查 v$tempfile）；1289 是否在该文件有效块范围内（blocks 字段值 × block_size ≤ 文件大小）。
查到段之后，下一步动作取决于段类型
不同对象类型修复路径差异极大，不能一概而论：
- 如果是
segment_type = 'INDEX'：优先ALTER INDEX ... REBUILD，索引可完全重建，不影响原始数据 - 如果是
segment_type = 'TABLE'：不能直接 rebuild，需导出可用行（如CREATE TABLE t_good AS SELECT * FROM t WHERE rowid NOT IN (SELECT rowid FROM t WHERE ...)），再重建表 - 如果是
segment_type = 'LOBSEGMENT'：需结合DBMS_REPAIR.SKIP_CORRUPT_BLOCKS临时跳过，否则SELECT可能持续失败 - 如果查不到任何段（即
DBA_EXTENTS无返回），坏块大概率在数据字典或系统段，此时必须依赖 RMAN 块恢复或从备份还原
容易忽略的关键点：RFN vs AFN
报错里的 file # 是相对文件号（RFN），而 DBA_EXTENTS.FILE_ID 存的是绝对文件号（AFN）。两者不等价：
-
SELECT file_id, relative_fno, file_name FROM dba_data_files查清映射关系 - 若
ORA-01578提示file # 5，但dba_data_files中没有relative_fno = 5的行，说明它可能是临时文件或已删除的数据文件（此时需查v$tempfile或v$datafile的历史状态） - 误用 RFN 当作 AFN 去查
DBA_EXTENTS，必然查不到结果
真正麻烦的不是查不到段，而是查到段后发现它是 SYSTEM 表空间里的字典表——这时候 DBA_EXTENTS 能告诉你“坏了哪儿”，但修不了，只能靠备份或 Oracle Support 协助。
