RMAN BLOCKRECOVER要求数据库必须处于MOUNT状态，否则无法执行；需已知确切file#和block#，来源包括alert.log、DBV或trace文件；仅支持从备份集恢复，不支持影像副本；真正数据提取需依赖EVENT跳过或重建等非RMAN手段。
ORA-600 错误本身不提供“提取可用块”的能力，RMAN 的 BLOCKRECOVER 也不是数据导出工具；它只修复或跳过坏块，前提是知道具体文件号和块号，且数据库能 mount。
RMAN BLOCKRECOVER 要求数据库处于 MOUNT 状态
这是最常被忽略的前提。如果数据库连 STARTUP MOUNT 都失败（比如 ORA-600[kcratr_nab_less_than_odr] 或 [kcratr1_lastbwr]），BLOCKRECOVER 根本无法执行。此时 RMAN 连目标实例都连不上，所有 block-level 操作都无从谈起。
常见卡点：
- 控制文件损坏或 SCN 不一致，导致无法 mount
- 当前 redo log 损坏（尤其单成员、未归档场景），open 阶段直接 abort
- SYSTEM 表空间头块或数据字典块坏，mount 后立即报错
必须先定位到确切的 file# 和 block#
RMAN 不会主动扫描坏块；它只按你给的坐标操作。这些坐标必须来自：
- alert.log 中的
Corrupt Block Found行（如TSN = 1, RFN = 2, BLK = 10123） - DBV 输出（
dbv file=/path/to/data01.dbf） - trace 文件里明确的
file 58 block 367365
没有这些信息，BLOCKRECOVER 就是盲操作。乱填参数不仅无效，还可能触发二次报错（如 ORA-19566）。
实际能用的 RMAN 坏块恢复命令只有三类
以下命令全部要求数据库已 MOUNT，且对应数据文件在线（非 OFFLINE DROP）：
-
BLOCKRECOVER DATAFILE 2 BLOCK 10123;—— 单块修复，依赖最近可用备份 + 归档日志 -
BLOCKRECOVER CORRUPTION LIST;—— 仅对上次BACKUP VALIDATE CHECK LOGICAL发现的坏块生效 -
BLOCKRECOVER DATABASE FROM BACKUPSET;—— 全库级，需指定 backupset key，极少用于单坏块场景
注意：FROM COPY 不适用 —— 影像副本（image copy）不支持块级恢复；FROM SERVICE 仅限 12c+ DG 场景，且主库必须正常。
真正“提取可用数据”的路子不在 RMAN
当坏块在关键对象（如 LOB segment、索引根块、undo segment）上，且无有效备份时，RMAN 修不了，也提不出数据。这时唯一可行路径是：
- 用
EVENT='10231 trace name context forever, level 10'跳过全表扫描坏块（仅限 SELECT） - 对受损表用
CREATE TABLE AS SELECT ... WHERE ROWID NOT IN (SELECT ROWID FROM ...)排除已知坏块 ROWID - LOB 坏块常用
ALTER TABLE ... MOVE LOB(...) STORE AS (...)强制重建段（如SYS_LOB0000010129C00001$$）
这些操作不依赖 RMAN，但要求数据库至少能 OPEN（哪怕只读），且必须提前确认坏块是否影响事务回滚 —— 否则 SMON 可能反复 crash，触发新 ORA-600。
坏块位置越靠近数据字典或 undo，可操作窗口越窄。别指望 RMAN 当数据泵用；它只管块，不管行，更不管语义。
