DBV是唯一安全的物理坏块检测方式，只读校验数据文件、不触发数据库操作、不依赖归档模式；坏块需按对象粒度定位处理，索引坏块应删除重建，表坏块则通过10231事件或DBMS_REPAIR跳过，SYSTEM/UNDO坏块必须依赖备份修复。
能直接定位坏块位置并分对象类型处理，就别盲目重建整个表空间——检测和修复必须按对象粒度来，否则容易误删数据或引发连锁故障。
DBV 是唯一安全的物理坏块检测方式
DBV（dbv）是 Oracle 自带的只读校验工具，不触发任何数据库内部操作，不会导致实例崩溃，也不依赖归档模式或数据库是否在线。RMAN VALIDATE、EXPDP、全库扫描等都可能加载损坏块到内存，极端情况下直接宕库。
-
dbv只能校验数据文件（.dbf），不支持控制文件、日志文件 - 必须指定
blocksize，常见值为8192、16384，可通过SELECT value FROM v$parameter WHERE name = 'db_block_size'确认 - 输出中明确标注
Corrupt行，含file_id、block_id、corruption type（如Frmt表示格式错误，Chksum表示校验和失败） - 若 DBV 报错 “Failed to open file”，说明文件权限或路径错误，不是坏块问题
用 V$DATABASE_BLOCK_CORRUPTION 快速确认逻辑坏块
这个视图只记录被数据库实际访问时发现的坏块（比如查询、DML 触发），属于“事后上报”，不能替代 DBV 的主动扫描。但它能告诉你坏块当前是否已被数据库感知，以及是否影响业务。
- 执行
SELECT * FROM V$DATABASE_BLOCK_CORRUPTION，有结果即表示已有坏块被识别 -
corruption_type字段区分物理损坏（ALL ZERO、FRACTURED）和逻辑损坏（LOGICAL） - 该视图内容在数据库重启后清空，所以它反映的是当前实例生命周期内的坏块状态
- 如果视图为空但 DBV 报坏块，说明坏块尚未被访问过，风险仍在，但暂未暴露
索引坏块：删掉重建最稳妥
索引是冗余结构，不存原始数据，坏块不影响主表数据完整性。但 ALTER INDEX ... REBUILD 会尝试读取坏块，大概率失败；必须走“删除 + 重建”路径。
- 先查坏块归属：
SELECT segment_name, segment_type FROM dba_extents WHERE file_id = <file_id> AND <block_id> BETWEEN block_id AND block_id + blocks - 1 - 确认
segment_type = 'INDEX'后，直接DROP INDEX schema.index_name - 重建时注意原定义：包括表空间、
PCTFREE、INITRANS、PARALLEL等参数，否则可能影响性能 - 重建完成后，
ANALYZE INDEX ... VALIDATE STRUCTURE可验证结构一致性
表坏块：跳过比修复更现实（尤其无备份时）
表坏块意味着部分行数据不可读，无法“修复”已损坏的块内容。官方方案只有两种：一是临时跳过（event 10231），二是永久标记（DBMS_REPAIR）。二者都不恢复数据，只是让查询绕开坏块。
-
event 10231是会话级设置，仅对当前会话生效：ALTER SESSION SET EVENTS '10231 trace name context forever, level 10' -
DBMS_REPAIR需先建修复表：BEGIN DBMS_REPAIR.ADMIN_TABLES('REPAIR_TABLE', DBMS_REPAIR.REPAIR_TABLE, DBMS_REPAIR.CREATE_ACTION); END; - 标记后，
SELECT不再报ORA-01578，但坏块对应行永远不可见；INSERT/UPDATE仍可正常写入其他块 - 注意：
DBMS_REPAIR不适用于 SYSTEM、UNDO、SYSAUX 表空间中的对象，这些必须靠备份恢复
真正难处理的是 SYSTEM 或 UNDO 表空间坏块——它们没有“跳过”的余地，一旦损坏，数据库很可能无法启动。这时候 DBV 结果只是起点，后续必须结合告警日志里的 ORA-600 参数、回滚段名、数据字典对象名做定向干预，而所有操作的前提都是已做完物理全库备份。
