ABMR仅修复物理坏块且需同时满足四个硬性前提：DG_CONFIG配置正确、LOG_ARCHIVE_DEST_n含VALID_FOR、备库OPEN READ ONLY WITH APPLY且MRP运行中、坏块为I/O层物理损坏；逻辑坏块不触发ABMR。
Oracle 19c Active Data Guard 的自动块修复（ABMR）只在满足全部四个硬性前提时才真正生效，缺一不可；它不修逻辑坏块，也不响应人为跳过校验的读取操作。
ABMR 触发的四个必要条件
ABMR 不是“开了 ADG 就自动工作”的功能。它依赖一组精确协同的配置和状态：
-
LOG_ARCHIVE_CONFIG必须包含主备双方的DG_CONFIG条目，例如：'DG_CONFIG=(orcl_primary,orcl_standby)' - 主库上至少一个
LOG_ARCHIVE_DEST_n需启用SYNC或ASYNC并配置VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，且DB_UNIQUE_NAME匹配备库 - 备库必须处于
OPEN READ ONLY WITH APPLY状态，并且重做应用进程（MRP）正在运行 —— 用SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;确认MRP行的STATUS是APPLYING_LOG - 坏块必须是物理坏块：即 I/O 层面读取失败（
ORA-01578）、块头校验和不匹配、或块类型/格式非法；逻辑坏块（如索引键重复、约束冲突）会直接报错，不进 ABMR 流程
如何验证 ABMR 实际在工作
不能靠“没报错”就认为 ABMR 生效了。真实验证要盯日志和现象：
- 在主库模拟坏块后（例如用
dd损坏数据文件某块），执行SELECT * FROM test.adg WHERE rowid = 'AAAUYWAAHAAAACLAAW';—— 若返回数据且无ORA-01578，说明 ABMR 已介入 - 立即检查主库
alert.log，搜索关键词Automatic block media recovery，应出现类似：Automatic block media recovery: successfully restored block 139 from orcl_standby - 若只看到
ORA-01578+ORA-26040，说明 ABMR 未触发 —— 常见原因是备库 MRP 停了、LOG_ARCHIVE_DEST_n配置缺失VALID_FOR、或坏块实际是逻辑型（比如被BLOCK RECOVER手动修复过但未清缓存）
ABMR 修复失败的三个典型坑
很多 DBA 在测试中“以为修好了”，结果上线后失效，问题常出在这些细节：
- 备库开启了
STANDBY NOLOGGING FOR LOAD PERFORMANCE模式：该模式允许主库批量加载时暂不传数据到备库，导致备库对应块为空或陈旧，ABMR 取不到干净副本 —— 生产环境慎用，优先选FOR DATA AVAILABILITY - 主库损坏的是临时表空间（
TEMP）或撤销表空间（UNDO）中的块：ABMR 不覆盖这两类文件，因为它们不参与 Redo Apply 同步，也不会从备库拉取 - 客户端连接使用了连接池且未设
RETRY_COUNT：ABMR 修复后需客户端重试读取，若连接池直接抛异常并关闭连接，应用层收不到“第二次成功”的结果 —— 建议在 JDBC URL 中加retryCount=2或等价参数
ABMR 的透明性是双刃剑：它不写入数据字典、不生成备份集、不改变对象结构，所以你无法通过 DBA_CORRUPT_BLOCKS 查到它“修过什么”。真正要确认它是否可靠，只能在可控环境下反复模拟物理坏块并核对 alert 日志里的那行 successfully restored block —— 其他都是推测。
