块级恢复前必须确认三件事：①数据库处于open状态；②已准确定位坏块（来自v$database_block_corruption或告警日志）；③启用archivelog且存在覆盖坏块时间点的可用备份（含该块的最近备份及后续归档日志）。
块级恢复前必须确认的三件事
不能直接 BLOCKRECOVER，否则报 RMAN-06571（目标数据文件未处于 ONLINE 状态）或静默失败。先确认：① 数据库是 OPEN 状态；② 损坏块已定位（来自 v$database_block_corruption 或告警日志，如 Corrupt block relative dba: 0x01000123 (file 4, block 291)）；③ 归档已启用且有可用备份（含该块的最近备份 + 后续归档日志）。缺一不可。
执行 BLOCKRECOVER 的典型命令组合
Oracle 会自动匹配备份、提取块、应用归档日志并写回原位置，全程不中断业务。常用写法有：
-
BLOCKRECOVER DATAFILE 4 BLOCK 291;—— 最简形式，适用于单块 -
BLOCKRECOVER DATAFILE 4 BLOCK 291, 292, 295;—— 多块连续或离散，用逗号分隔 -
BLOCKRECOVER TABLESPACE users;—— 自动扫描该表空间所有已知坏块（需先运行VALIDATE CHECK LOGICAL） -
BLOCKRECOVER CORRUPTION LIST;—— 仅对v$database_block_corruption中当前标记的坏块生效
注意：BLOCKRECOVER 不接受 FROM BACKUPSET 这类显式指定备份源的子句——RMAN 自动选择最优备份，强行指定反而可能触发 RMAN-06026（找不到匹配备份）。
为什么 BLOCKRECOVER 有时找不到备份？
常见原因不是备份真丢了，而是状态不一致：
- 控制文件里没记录该块所在备份——执行过
CATALOG START WITH但漏了归档路径，或备份后手动删过控制文件快照 - 损坏块所属的数据文件被重建过（比如用
CREATE DATAFILE），但控制文件仍指向旧文件号，导致 RMAN 匹配失败 - 使用了恢复目录但未同步（
RESYNC CATALOG缺失），而控制文件中该块的 SCN 范围已过期
验证方法：运行 LIST BACKUP OF DATAFILE 4; 看输出是否包含时间戳覆盖坏块发生时刻的备份；再查 V$BACKUP_CORRUPTION 是否为空——非空说明 RMAN 已识别到备份中的坏块，此时 BLOCKRECOVER 会跳过该备份。
恢复后必须做的验证动作
块级恢复不自动清除 v$database_block_corruption 视图里的记录，也不校验关联对象（如索引段）逻辑一致性：
- 立即运行
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE;检查表+索引是否可访问 - 查
SELECT * FROM v$database_block_corruption WHERE file# = 4;确认记录已清空 - 若之前因坏块导致查询报
ORA-01578，现在应能正常返回结果；但若曾用DBMS_REPAIR标记过段，需额外执行DBMS_REPAIR.SKIP_CORRUPT_BLOCKS关闭跳过模式
真正容易被忽略的是：块恢复成功后，如果该块属于 LOB 段，DBA_LOBS 中的 CHUNK 计数可能滞后，需配合 DBMS_LOB.VALIDATE 手动校验，否则下次读取大对象时仍可能崩。
