dbv不能直接检查段空间，仅支持扫描物理数据文件；必须用dba_extents定位段所在文件路径，再以绝对路径+显式blocksize参数执行dbv校验，asm路径需先拷贝至本地，且“无坏块”结果不保证逻辑可用。
dbv 不能直接检查“段空间”，只能扫数据文件
dbv 工具压根不理解“段”（segment）这个逻辑概念，它只认操作系统级的文件路径。你执行 dbv file=users 或 dbv segment_id=... 都会失败——因为 segment_id 参数在 11g 中仅用于内部调试，**不支持用户指定段来扫描**。真正能用的只有 file 参数，且必须是绝对路径，比如 /u01/oradata/orcl/users01.dbf。
常见错误现象：ORA-27041: unable to open file 或直接提示 “file not found”，基本都是传了表空间名、段名或 ASM 路径。
- 查段所在文件：先用
SELECT file_id, block_id, blocks FROM dba_extents WHERE owner = 'SCOTT' AND segment_name = 'EMP'定位物理位置 - 再查该
file_id对应的真实路径：SELECT file_name FROM dba_data_files WHERE file_id = 4 - 最后对那个
file_name执行dbv，别跳过任何文件
扫描时必须显式指定 BLOCKSIZE，否则结果全不可信
Oracle 11g 支持非默认块大小（如 16K 表空间），而 dbv 默认按 8192 字节解析。如果目标文件块大小是 16384，但没加 BLOCKSIZE=16384，它会把两个真实块拼成一个伪块去校验，导致 Total Pages Marked Corrupt 显示为 0，实际已漏检大量坏块。
- 查真实块大小：
SELECT tablespace_name, block_size FROM dba_tablespaces WHERE tablespace_name = 'USERS' - 扫描时必须带上：
dbv file=/path/to/users01.dbf BLOCKSIZE=16384 - 若混用多种块大小（比如一个表空间里有多个不同 BLOCKSIZE 的文件），每个文件都得单独指定参数
ASM 路径不能直传给 dbv，必须先拷贝到本地文件系统
dbv 是纯操作系统工具，不连接实例，也不调用 ASM API。传 file=+DATA/ORCL/DATAFILE/users.256.12345 会直接报错，连文件都打不开。
- 先用
asmcmd cp拷出来：asmcmd cp +DATA/ORCL/DATAFILE/users.256.12345 /tmp/users01.dbf - 确保目标路径有读权限，且文件未被其他进程锁定（比如 RMAN 备份中）
- 拷完立刻校验：
dbv file=/tmp/users01.dbf BLOCKSIZE=8192 LOGFILE=/tmp/dbv_users.log - 别忘了清理临时文件，尤其当
/tmp空间紧张时
扫出坏块后，定位段对象要靠 DBA_EXTENTS，但要注意范围边界
dbv 输出只会告诉你 File 4, Block 524 坏了，不会说属于哪张表。这时候必须进数据库查 DBA_EXTENTS，但它的 BLOCK_ID 和 BLOCKS 是包含关系，不是精确映射。
- 正确查询语句：
SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = 4 AND 524 BETWEEN block_id AND block_id + blocks - 1 - 注意：
dba_extents只返回已分配段的空间，空闲块、段头块、位图块这些不在此列，坏了也不会出现在结果里 - 如果查不到结果，说明坏块可能落在空闲区、SYSTEM 表空间的特殊块，或已被 drop 但未回收的段残留区
最易被忽略的一点：dbv 的“通过”只代表块结构没破，不代表数据可用；ORA-01578 仍可能在 SQL 执行时爆发。真要确认逻辑一致性，得配合 ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE 或 RMAN VALIDATE CHECK LOGICAL。
