abmr仅修复物理坏块且需四前提全满足：_auto_bmr=enable、物理坏块、主备网络连通、备库启用实时应用；须查alert日志确认“fetching block”行，否则未生效。
ABMR（Automatic Block Media Recovery）只在满足全部四个硬性前提时才真正生效，缺一不可。不是“开了ADG就自动修”，更不是“主备连着就能拉块”。多数人卡在第一步：误以为坏块报错出现就代表ABMR已介入，结果查日志才发现压根没触发。
确认 ABMR 是否真在工作，而不是靠“感觉”
ORA-01578 出现后客户端没报错、查询照常返回，不代表ABMR成功——可能只是缓存里还有旧块，或SQL绕过了损坏区域。必须看主库或备库的 alert 日志里有没有类似这样的行：
Automatic block media recovery: fetching block 131 from file 29 on instance sdswhxcxdg
没有这行，说明ABMR根本没启动。常见原因包括：
-
_auto_bmr隐含参数被设为DISABLE（默认是ENABLE，但有人手动关过） - 坏块类型是逻辑坏块（比如索引条目指向错误数据块），
ABMR明确不处理这类问题 - 主库和备库之间网络不通，或 TNS 连接超时（受
_auto_bmr_req_timeout控制，默认 60 秒） - 备库处于
READ ONLY模式但未启用实时应用（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE缺失）
RMAN 恢复单块前必须停掉 MRP 进程
当ABMR没触发、又确认只是物理坏块时，RMAN RECOVER DATAFILE N BLOCK m 是最直接的补救手段。但它有个死线条件：备库数据库必须处于 MOUNT 状态，且 MRP0 进程必须完全退出。
只执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL 不够——它只是发取消信号，MRP0 可能还在清理归档队列。务必验证：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';
返回空行才算安全。否则 RMAN 会报错：ORA-19566: exceeded limit of 0 corrupt blocks for file 或直接 hang 住。
另外注意 RMAN 连接方式：rman target /（用操作系统认证），不能写成 rman target sys/password@db，否则容易因密码文件同步延迟或监听配置失败而连接不上控制文件。
UNNAMED 文件 + ORA-01110 是最常被误判为“坏块”的场景
看到 ORA-01110 不要急着修块。先查 DBA_DATA_FILES：
SELECT FILE_ID, FILE_NAME, STATUS, ONLINE_STATUS FROM DBA_DATA_FILES WHERE FILE_ID = N;
如果 FILE_NAME 是 /u01//UNNAMED00043，那根本不是坏块，而是备库没自动创建新数据文件。这是 standby_file_management=AUTO 失效导致的典型同步断点。
修复路径很固定：
- 临时切手动：
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH; - 按主库真实路径重建：
ALTER DATABASE CREATE DATAFILE '/u01//UNNAMED00043' AS '+DG_DATA02/racdbdg/users02.dbf';（注意 ASM 磁盘组权限和db_file_name_convert规则） - 立刻切回自动：
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH; - 重启恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
漏掉最后一步，MRP 就不会继续拉归档，后续所有新对象都不同步。
ABMR 和 RMAN 块恢复不能共存
两者机制冲突：ABMR 是运行时从远端实时拉块覆盖，RMAN RECOVER ... BLOCK 是离线用归档/备份重演。如果在 MRP 运行中强行跑 RMAN 块恢复，轻则报错中断，重则导致备库控制文件与实际数据文件状态不一致。
反过来，如果你已经用 RMAN 修好了块，记得检查 V$DATABASE_BLOCK_CORRUPTION 是否清空：
SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
有残留记录的话，ABMR 下次遇到同位置读取仍会尝试拉块——浪费网络资源，还可能因主库该块也已变更而拉到过期内容。
最易被忽略的一点：ABMR 修复的是“当前正在读的块”，它不扫描全库；RMAN 块恢复只修指定块号，不校验相邻块。一次坏块背后，往往藏着磁盘早期预警信号——别修完就走，得查 ASM 的 v$asm_disk_iostat 或底层存储 SMART 日志。
