abmr触发需同时满足四个硬性前提：主备库均启用active data guard、运行real-time apply、损坏为物理坏块、损坏块属可远程获取的读写表空间；缺一则仅报ora-01578。

Oracle 19c Active Data Guard 的自动块修复（ABMR）不是“开箱即用”的功能，它依赖四个硬性前提同时满足才能触发——缺一不可，否则即使出现物理坏块，也只会报 ORA-01578 并中断查询。

ABMR 触发的四个必要条件

ABMR 不是靠开关控制的“功能”，而是内核在特定路径下自动走通的恢复流程。以下四点必须全部为真：

• 主库和备库都必须启用 ACTIVE DATA GUARD（即备库处于 READ ONLY WITH APPLY 状态）
• 主备库之间必须运行 REAL-TIME APPLY（非归档日志应用模式）
• 损坏必须是物理坏块（Physical Block Corruption），比如磁盘读取失败、校验和不匹配；逻辑坏块（如索引与表数据不一致）完全不处理
• 损坏块所属的数据文件必须属于主库或备库中“可被远程获取”的范围——即不能是临时表空间、undo 表空间或只读表空间中的块（这些块不参与 ABMR 流程）

_auto_bmr 隐含参数只是开关，不是保障

该参数控制 ABMR 请求器是否启动，默认为 ENABLE，但仅表示“允许发起修复请求”，不代表一定能修成功。常见误操作：

Agent Git Oracle

高级仓库分析与重构指南。基于AI推理识别技术债务与架构反模式。

下载

• 直接修改 _auto_bmr = DISABLE 来禁用 ABMR：没必要，ABMR 本身不消耗资源，只在坏块发生时才激活
• 以为改了参数就万事大吉：实际 ABMR 还受 _auto_bmr_req_timeout（默认 60 秒）、_auto_bmr_sess_threshold（默认 30 个会话）等隐含参数节流，超限后会静默丢弃请求
• 在 RAC 环境中只在一个实例上查 x$ksppcv：需确认所有实例该参数值一致，否则部分节点无法响应修复请求

验证 ABMR 是否真正在工作

别信 SHOW PARAMETER _auto_bmr，要查真实日志信号：

• 主库 alert 日志中出现类似行：Automatic block media recovery: successfully restored block 131 from orcl_standby
• 备库 alert 日志中对应时间点有 Block media recovery request received from primary
• 查询 V$DATABASE_BLOCK_CORRUPTION：ABMR 成功后该视图应为空；若仍有记录，说明是逻辑坏块或不满足上述任一前提
• 用 dd 在测试表空间人工制造一个物理坏块（如 dd if=/dev/zero of=... bs=8192 seek=131 count=1 conv=notrunc），再执行 SELECT COUNT(*) FROM test_table —— 若无 ORA-01578 且返回结果正常，ABMR 已生效

ABMR 修不了的坏块，你得手动干

ABMR 只救物理坏块，对以下情况完全无能为力：

• ORA-08102（索引键不匹配）、ORA-01499（索引/表不一致）等典型逻辑坏块
• 损坏发生在备库的只读表空间（如 SYSTEM 中只读对象）
• 主库损坏块所在数据文件被设为 OFFLINE 或 RECOVER 状态
• 网络延迟 > _auto_bmr_req_timeout，导致备库未在超时前返回干净块副本

这类问题必须走传统路径：用 RMAN BLOCKRECOVER + 备份，或从主库拉完整数据文件重建，ABMR 不介入。