RMAN RECOVER BLOCK是用于修复单个或多个数据块逻辑损坏（如ORA-01578）的命令，需归档模式、完整备份、归档日志及控制文件；不支持物理损坏、SYSTEM/UNDO表空间及无备份的块。
什么是RMAN RECOVER BLOCK，它能修什么
recover block 是 rman 提供的逻辑块级别修复能力，专用于修复单个或多个数据块的**逻辑损坏**（如 ora-01578、ora-01110 报出的块校验失败），但前提是：数据库必须运行在归档模式，且有可用的完整备份 + 归档日志 + 控制文件（或控制文件备份）。
它不能修复物理损坏（比如磁盘坏道导致的读取失败）、不能修复丢失的数据文件头、也不能绕过控制文件直接恢复——所有块定位和一致性校验都依赖控制文件中的块地址（file# 和 block#）。
常见误用场景：看到 ORA-01578 就直接跑 RECOVER BLOCK，结果报错 RMAN-06026: some targets not found——往往是因为目标块所属的数据文件没被 RMAN 备份过，或者备份已过期/不可用。
执行 RECOVER BLOCK 前必须确认的 4 件事
不是所有逻辑坏块都能“一键修复”，得先验证环境是否满足硬性条件：
- 数据库处于
OPEN或MOUNT状态（OPEN更常用，因为能在线修复） - 损坏块所在的表空间不能是
SYSTEM、UNDO或临时表空间（RECOVER BLOCK不支持这些） - RMAN 中已注册了至少一份包含该块的**完整数据文件备份**（增量备份无效，必须是 level 0）
- 归档日志链完整，能覆盖从备份时间点到当前 SCN（可通过
LIST ARCHIVELOG ALL+CROSSCHECK ARCHIVELOG ALL验证）
漏掉任意一项，命令会中途失败，典型错误包括：RMAN-06023: no backup or copy of datafile found、RMAN-06025: no backup of log thread 1 seq 123456 found。
怎么定位并指定要修复的块
不能靠猜。ORA-01578 错误里带的 file# 和 block# 是唯一可靠依据（例如 ORA-01578: ORACLE data block corrupted (file # 5, block # 12345)）。如果错误来自查询，需先查 V$DATABASE_BLOCK_CORRUPTION 视图确认：
SELECT file#, block#, blocks, corruption_type FROM V$DATABASE_BLOCK_CORRUPTION;
然后构造 RMAN 命令：
RMAN> RECOVER BLOCK 5 BLOCK 12345; RMAN> RECOVER BLOCK 5 BLOCK 12345, 12346, 12347;
注意：BLOCK 关键字后只跟数字，不加引号；多块用英文逗号分隔，不能有空格；若跨文件，需重复写 FILE 子句：RECOVER BLOCK 5 BLOCK 12345, 6 BLOCK 999。
别试图用 RECOVER BLOCK 修复整个数据文件——那是 RESTORE DATAFILE 的事，效率低且中断业务。
修复失败后最常被忽略的两个细节
即使所有前置检查都通过，修复仍可能静默失败或部分成功。这时要盯住两处输出：
- RMAN 日志末尾是否出现
Finished recover at ...（成功标志），还是停在starting media recovery后无响应（大概率归档日志缺失） - 修复后立即查
V$DATABASE_BLOCK_CORRUPTION是否清空——有时块被标记为“已修复”，但下次 checkpoint 后又复现，说明底层备份本身已含逻辑损坏（比如备份时数据库就存在未提交的坏事务）
另外，RECOVER BLOCK 默认使用 DB_FILE_NAME_CONVERT 或控制文件路径还原块，如果目标库用了 ASM，而备份在文件系统，RMAN 可能找不到对应文件——此时需提前用 SET DBID 和 SET CONTROLFILE AUTOBACKUP FORMAT 显式指定上下文。
